There's more...

The refactoring can be developed a bit more by extracting other useful values from the workflow context and implementing some more reusable functions in the base class. However, this was not necessary for our scenario.

Follow the YAGNI principle: You aren't gonna need it. Keep your classes simple and start by only implementing only what you need. If new scenarios appear, add more as required. With simplicity comes ease of readability, which equates to ease of maintenance, improved performance (due to the lack of layering overhead), improved reliability (as you are not introducing potential defects related to the unnecessary code), and your code will be faster and cheaper to implement, among other qualities.
As per the plugin, Development Toolkit also includes an abstract workflow base class that can be reused.

Note how we have two ways of extracting the primary entity's GUID in step 11. The first scenario, WorkflowContext.PrimaryEntityId, caters for a custom workflow activity. The second (where the input holds the GUID) caters for custom action. Not only did we refactor our plugin into a workflow activity, but we also catered for this activity to be converted into an action (as described in Creating your first custom action in Chapter 4, Server-Side Extensions).

As mentioned in the first recipe of this chapter, we can further change the entry point into a console application that accepts a GUID parameter, effectively turning the code into a portable smoke test executable. We can also integrate the business logic into a unit test (as described in the next recipe, Unit testing your plugin business logic).

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.141.41.187