Properties vs. Arguments
There are several options available for passing data into an activity. In addition to using InArgument, activities can also be developed that receive data using either standard CLR Properties or public ActivityAction properties. This topic discusses how to select the appropriate method type.
Using CLR Properties
When passing data into an activity, CLR properties (that is, public methods that use Get and Set routines to expose data) are the option that has the most restrictions. The value of a parameter passed into a CLR property must be known when the solution is compiled; this value will be the same for every instance of the workflow. In this way, a value passed into a CLR property is similar to a constant defined in code; this value can’t change for the life of the activity, and can’t be changed for different instances of the activity. MethodName is an example of a CLR property exposed by an activity; the method name that the activity calls can’t be changed based on runtime conditions, and will be the same for every instance of the activity.
Arguments should be used when data is only evaluated once during the lifetime of the activity; that is, its value will not change during the lifetime of the activity, but the value can be different for different instances of the activity. Condition is an example of a value that gets evaluated once; therefore it is defined as an argument. Text is another example of a method that should be defined as an argument, since it is only evaluated once during the activity’s execution, but it can be different for different instances of the activity.
When data needs to be evaluated multiple times during the lifetime of an activity’s execution, an ActivityAction should be used. For example, the Condition property is evaluated for each iteration of the While loop. If an InArgument were used for this purpose, the loop would never exit, since the argument would not be reevaluated for each iteration, and would always return the same result.