Using Base Classes for Plugins - rezanid/xrmtools GitHub Wiki

Xrm Tools is flexible and can adapt to different project structures or advanced requirements. Here are a couple of patterns and extensibility points for advanced users:

1. Using Base Classes for Plugins: You might have common logic that you want to reuse across multiple plugins. For example, you may create an abstract PluginBase class that implements IPlugin.Execute, does some initial common work (like obtaining services from the provider, or handling error logging uniformly), and then calls an abstract method that derived classes implement. Xrm Tools works well with this pattern:

• You can still put [Plugin], [Step], etc., on the derived classes.
• If PluginBase sets up some services (like a tracing service) and you want the derived classes to use that instead of creating their own, mark the base property as [DependencyProvider] (as shown in the DI example). Derived plugins can then declare a [Dependency] on something that matches the type, and Xrm Tools will inject the base-provided instance.
• Xrm Tools code generation will include base class properties in consideration. It won’t override your base class logic; You would call methods you need in the generated partial class.
• Pattern example: Have PluginBase retrieve IPluginExecutionContext and IOrganizationService from IServiceProvider and maybe store them or wrap them in a context object. Then in your derived plugin’s Execute, you call into that context. Xrm Tools doesn’t mind this structure at all. The attributes still go on the derived class.
• This pattern helps maintain DRY (Don’t Repeat Yourself) principles by putting shared setup or utilities in one place.