Plugin Class Organization

Like (0) Share

Report

Posted on 27 Apr 2021 21:26:31 by Daryl LaBar

156 Most Valuable Professional

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?

All responses (3)

Answers (0)

Tanguy TOUZARD 113 Most Valuable Professional on 28 Apr 2021 at 17:58:38

Like (0)

Report

Re: Plugin Class Organization

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.
Diana Birkelbach 3,072 Most Valuable Professional on 28 Apr 2021 at 12:42:37

Like (1)

Report

Re: Plugin Class Organization

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.

Kind regards,

Diana
Daryl LaBar 156 Most Valuable Professional on 27 Apr 2021 at 22:05:35

Like (0)

Report
Re: Plugin Class Organization

I've seen a couple approaches, but they all come with their own positives/negatives:
One single class - In this case a single class is used for all plugin registrations, and the code must inspect the context to determine what is being executed (usually a list of nested, ugly long switch statements), and then it calls out to the appropriate logic
Positives:
Only a single plugin class to pick for registering a plugin step makes it impossible to pick the wrong plugin
Could be more performant.
Less plugins needing to be loaded
Could make better use of caching, allowing shared date that is required for multiple logic pieces to be retrieved once
Could allow for a single update at the end of the plugin logic, rather than multiple updates
Negatives
(Usually) Ugly logic for determining what logic is executed
What gets executed is hard coded. (What if there are three separate things that should be done on account creation, but for a period of time, only 2 should be performed? A user can disable a plugin step, but redeploying a plugin is generally not possible in prod, one hopes)
Logic becomes interdependent
Additional checks for "Should this logic run?" have to be performed and known ahead of time, rather than relying on the plugin step registrations to dictate what is executed.
One class per Table - Similar to #1, but broken out at the table level
Positives:
All the same as Option #1 above, but a little less positive since it is now split up by table.
The ugly logic for determining what logic is executed is split up into smaller segments (by table, rather than by org)
Naming is simple, AccountPlugin, ContactPlugin, etc...
Negatives:
All the same as Option #1 above, but a little less negative since it is not split up by table.
What if the same logic is ran against multiple tables? What table name do you list in the plugin? All of them? AccountAndContactPlugin? what if a third table is added? Now all registrations have to be re-added
One class per registration step - So AccountPreOpUpdate or ContactPreValidationCreate or LeadPostOpQualify
Positives
(Usually) Complete control over what logic is executing via plugin step registration (Although configuring this could get very very very ugly if there are interdependencies between steps i.e. PluginA must run or else PluginB will fail)
Low probability of having multiple sets of logic in a single class.
Negatives
Makes it very difficult to know why the plugin was created InitializeWithLinkedInDataPlugin is way more descriptive and discoverable than ContactPreCreate.
Instances where there are separate logic (i.e. LogAccountCreation and PopulateAccountDataOnCreate) either require even more plugins with similar names, or hard coded logic.
One class per Business Process - ie FormatPhoneNumbersPlugin,
Positives
Self descriptive.
Isolatable
Easy to know the plugin is doing
Negatives
Harder to know what plugin step it should be registered for

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.