I posted previously about Plugin Class/Assembly Management/Organization for ALM, where the general answer is to have the least number of plugin assemblies as possible for simplifying ALM processes (generally this would be one). Assuming that the single plugin assembly approach is being followed, how should the plugin classes be divided/organized?
I've seen a couple approaches, but they all come with their own positives/negatives:
I tend to lean primarily on the approach #4, unless the plugin logic is literally a couple lines and is hard to describe as a business process, then I'll go with a some #3. It's not perfect, but it works.
Hi @Dlabar ,
I tend to go with #3, because it gives the flexibility to the customizer/customer to enable/disable steps, and also to change the impersonation on every step if they change the permisions (or forgot to tell me that impersonation is needed). But of course, for more complex PlugIns, internally, I use several classes.
As a process (#4) I understand the implementation of a requirement, which might include several entities. Having only one class for that, I would lose a little from the flexibility.
I've seen PlugIns implemented as a class for all (#1): in my opinion is a nightmare considering the mantainability.
But as in the other thread, there might be ALM (or other) considerations that I am not aware of. I'm curious what the others recommend.
I’m using #2 with a base class where I have virtual methods for all message/stage combinations (like PreOperationCreate).
for tables that use the same logic, my plugins do not embed any business logic anyway. All business logic is on a separate project. So I can call the same logic from
multiple plugins, it does not duplicate the calls.
Check out new user group experience and if you are a leader please create your group
Check out how to claim yours today!
We are excited to announce that Demo Extravaganza for 2021 has started!
On-demand access to all the great content presented by the product teams and community members! #MSBizAppsSummit #CommunityRocks