cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
Dlabar
MVP

Plugin Class Organization

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?  

3 REPLIES 3
Dlabar
MVP

I've seen a couple approaches, but they all come with their own positives/negatives:

  1. 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.
  2. 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
  3. 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.
  4. 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.

DianaBirkelbach
Super User
Super User

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

TanguyT
MVP

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.

Helpful resources

Announcements
PA User Group

Welcome to the User Group Public Preview

Check out new user group experience and if you are a leader please create your group

secondImage

Demo Extravaganza is Back!

We are excited to announce that Demo Extravaganza for 2021 has started!

MBAS on Demand

Microsoft Business Applications Summit sessions

On-demand access to all the great content presented by the product teams and community members! #MSBizAppsSummit #CommunityRocks

Power Apps June 2021

June Power Apps Community Call

Did you miss the call? Check out the recording here!

Top Solution Authors
Users online (17,269)