Although it took us 11 steps to implement this structure, once the class hierarchy is there, it would only take us one step to create a new custom workflow activity. All we need is one class that inherits from BaseCustomWorkflow with a few lines of code to reuse the business logic code.

Similar to the Refactoring your plugin using a three-layer pattern recipe earlier in this chapter, we refactored our workflow entry into two classes: an abstract class that contains most of the generic reusable workflow routines (BaseCustomWorkflow step 3 to step 7) and a concrete specialized class (UpdateEmailsWorkflowActivity step 8 to step 11).

Similar to our abstract plugin base class, in step 6, we created a PostExecute method to override in our concrete class to which we passed the execution context. This pattern is slightly different from using protected variables. We passed the context as we only expect the scope of the context to be used within the PostExcute method. The workflow context is required to extract the input variables, as demonstrated in step 11.

Step 7 looks very similar to our refactored abstract plugin base; we extracted all the reusable common workflow bits into the parent class. The execute method deals with the DAL factory, extracts the common objects from the context, and deals with exception handling. The execute method calls the abstract PostExecute method, which is implemented in the concrete class.

Again, our concrete workflow child class looks very similar to our concrete plugin. The only difference is that we had to define an input variable in step 10 and retrieve its value in step 11. The rest of step 11 looks similar to our plugin, where we instantiated the business logic by injecting the concrete DAL from the factory, followed by calling the correct business logic method.