Most customization examples that you will find in books and official articles will mainly focus on the basics to get you started. They seldom delve deeper into how to structure your code for clean code and best practices. Any customization you build--whether using JavaScript, C#, or any other language or framework--should follow best practices. Plugins, for example, can very easily get too large and difficult to maintain if no thought is put into structuring them properly.

In this chapter we will start by refactoring our one class C# plugins into three layers: entry point, business logic, and data access layer (DAL). We will also introduce design patterns, such as dependency injection, singleton, and factory. Most of the enhancements will leverage fundamental object-oriented paradigms including: inheritance, encapsulation, and polymorphism, among others. A basic understanding of these patterns and paradigms is recommended, but not necessary.

The first recipe is key to the rest of the chapter, as it will enable some new capabilities. Most notably, this includes the ease of unit testing and the ease of swapping classes' implementations with minimum, if any, alterations to the rest of the dependent classes.

We will look at how easy it is to replace a complete DAL implementation in Replacing your LINQ data access layer with QueryExpressions, how easy it is to replace our logging class in Logging error from your customization, and how easy it is to convert a plugin into a custom workflow activity in Converting your plugin into a custom workflow activity, all in this chapter.

From a unit-testing perspective, we will be running a business logic unit test, a live integration test, and an end-to-end plugin test by using an in-memory organization service. Think of in-memory as a fake Dynamics 365 instance built in milliseconds for the purpose of our unit test.

The following simplified sequence diagram highlights some of the layers used in this chapter:

• The first sequence at the top traces the layers traversed when unit testing the business logic. As a true unit test, all dependent layers are either skipped or mocked.
• The second sequence in the middle highlights the live integration test, where the plugin is deployed to Dynamics 365 and triggered through the API to mimic a use case. All layers are invoked and the results are verified back in the live Dynamics 365 instance.
• The last sequence at the bottom traverses all the layers; it bypasses Dynamics 365 and uses an in-memory service context as shown here:

Different combinations are possible because of the multilayered refactoring. Regardless of whether you are building a pure .NET application or a Dynamics 365 extension, best practice and clean code rules apply.