We started this recipe by implementing a new class that inherits from the base DAL class and implements the IEmailDAL interface.

We implemented the required methods using the alternative design, but we also overrode some of the base class methods that did not quite work with our implementation. More specifically, in step 4, we used OrganizationService instead of OrganizationServiceContext. In step 5, given that we are not using OrganizationServiceContext, there was no need to have an implementation for the Commit method. The business logic will still call it, but the call is redundant. Nonetheless, the business logic correctness remains intact.

In step 7, we used the QueryExpression class along with OrganizationService RetrieveMultiple to retrieve the records we are interested in. Note how we filtered the number of returned columns to the ones we are interested in.

In step 8, we finally updated our factory class to return an instance of the newly created class.

Note how we didn't change anything in the plugin or the business logic. This is mainly due to the fact that these classes are not coupled with any concrete implementations. The plugin has a layer of separation to the DAL as it only cares about the business logic and the factory class. The business logic is only reliant on the interfaces; it does not care how the classes are implemented as long as they follow the same interface signature. This follows the Liskov substitution principle (L in the SOLID principle).