MSDN Magazine - December 2008 - (Page 53)

WF represents a logical next step in this march toward higher levels of programming abstraction. WF programs execute within a special runtime environment that itself runs on the .NET CLR. The WF runtime environment imposes some restrictions on the developer authoring programs that target it. But in return WF offers a powerful, flexible, and extensible set of runtime services such as support for long-running code, where execution might span days or even months; support for pausing/resuming/canceling running programs; support for auditing and tracing program execution; and even modification of running program logic! The heart of WF is its declarative programming model. That is, in WF you describe what you want your program to do, typically via the drag-and-drop WF designer in Visual Studio. However, you don’t specify exactly how this work should be accomplished. Instead, the WF runtime uses your program description (ultimately, a hierarchical graph of control flow and activities) as a blueprint for execution of your desired logic. It is common in component programming, WF in particular, to prefer composition over inheritance to achieve reuse. and inheritance is a natural technique for this. But if you need to conditionally send the e-mail only under certain circumstances or do other work before and after sending the e-mail, a better choice is to make SendEmailActivity a child of another CompositeActivity subclass (like SequenceActivity or IfElseActivity) and define the additional logic outside SendEmailActivity. Figure 1 shows a composite activity that encapsulates a conditional e-mail action. This allows SendEmailActivity to maintain a single responsibility (sending e-mails), thus increasing its chance for reuse in other workflows. It also allows you to reuse existing constructs in WF (support for conditional branching and sequential activity execution) instead of writing new code from scratch. The Workflow Programming Model Spend five minutes with the workflow designer in Visual Studio and it becomes obvious that WF is a component technology. A component in WF is an activity. More concretely, it is any subclass of the Activity base class. Activities are the unit of composition and execution in WF. Some activities—those that subclass CompositeActivity, which itself subclasses Activity—have child activities that execute as part of the parent activity’s execution sequence. Indeed, a workflow in WF is nothing more than a graph of such activities, starting with a single root activity and expanding to arbitrary depth and complexity. The innate logic of each activity in the graph, combined with data manipulated by this logic, ultimately determines execution order and overall workflow behavior. I like to think of WF activities as Lego blocks. With Legos, you combine individual blocks of varying color, size, and function (minimally useful on their own) to build a larger whole, greater than the sum of its parts. Similarly, in WF, you combine atomic activities that perform discrete functions to create higher-order sets of logic, which are then combined to realize still larger business processes, and so on. One pattern common to component programming in general (and WF in particular) is to prefer composition over inheritance to achieve reuse. As you work with WF over time and build increasingly complex workflows, you’ll more often find yourself composing programs from smaller, autonomous activities rather than creating deep class hierarchies along the lines of complex systems written in C# or Visual Basic. You’re still able to employ class inheritance as a reuse technique in WF. There’s nothing wrong with deriving from SendEmailActivity to create, say, SendEncryptedEmailActivity. In this case, you’re altering the fundamental nature of the action being performed, msdnmagazine.com In programming, a side effect is defined as an observable change to shared state that results from execution of some part of the program. Examples of this include a change in value to an object property, or a change to one or more values in a database table. Side effects are used all the time to accomplish real work in software. In contrast to pure functional programming where shared state is avoided and method return values are the primary means of data flow and manipulation, everything interesting in a workflow involves a side effect of some kind. Within a workflow program there is no such thing as a return value; instead, you compare preand post-execution state for changes. You dictate control flow not by calling methods, but rather by composing activities alongside and within one another. Activity inputs and outputs are implicit in the design of the activity class (as properties), rather than explic- Side Effect-Driven Programming Figure 1 A Custom Composite Activity with Conditional Logic December 2008 53 http://www.msdnmagazine.com

Table of Contents Feed for the Digital Edition of MSDN Magazine - December 2008

MSDN Magazine - December 2008 Contents Toolbox CLR Inside Out Advanced Basics Cutting Edge Patterns In Practice Team System Real-World WF Visual Studio OBA Tools SOA Data Access Geneva Framework Test Run Foundations Windows With C++ Going Places End Bracket

MSDN Magazine - December 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.