CRM Plugin Code Structure – By functionality or by event?

When we work on CRM plugins, there is a key decision at the beginning of the development cycle when it comes to structuring your plugin code. There are two main ways of writing your plugins :  by events or by functionality. In this post, I will describe the two approaches and discuss some of their pros and cons.

Plugins can be described as handlers for events fired by Microsoft Dynamics CRM (source). There can be multiple handlers for single events.  Let’s use an example for the purpose of this post.

For the event, we’ll use the creation of a case (pre operation). We will consider that when  the case is created, there are two actions that need to be performed : generate and assign a unique case number and validate that required fields have authorized values in them.

Plugin structured based on Events

For the plugin structure based on event, it means we’ll have a single plugin registered on the Case Pre create event, and inside the plugin class we’ll have two business logic blocks of code to execute (one to generate the unique number, the validate the required fields).

SNAGHTML4e81484     SNAGHTML4e74f7f

Plugin structured based on Functionality

In this case, we’ll have two plugin classes registered on the same event (again, one plugin for unique number generation and another to validate the required fields) – Sorry, no screen shot here but you get the idea Smile.

Pros and Cons

Functionality Based Plugins

  • Pros
    • Ease to see what plugins does what when looking at Plugin Registration tool (or similar tools) because of more descriptive feature name in plugin name
    • Ability to disable specific features for various scenario (e.g. disable system integration or auto calculation plugins during data migration)
    • Unit Tests can be written against a plugin class to test one functionality
    • Provides the ability to easily write generic plugins and register on multiple events by any power user
  • Cons
    • Large amount of plugin classes
    • Large amount of registered plugin steps; can become big and hard to read/maintain

Event Based Plugins

  • Pros
    • Plugin registration is straight forward and easy to maintain
    • Ease to easily the operations performed at each event when looking at the code
    • Plugin classes are standardized : always tied to an event and single point of entry for all developer to see actions executed on the event
    • Unit tests can be written against specific Business logic methods and/or classes (even independently from the plugin execution context depending on how they are written)
  • Cons
    • Must use alternate mechanism to disable specific features if needed (e.g. configuration data element)
    • Possible timeout if executing multiple large business logic blocs (mind you, if you have a timeout in a plugin – which happens after two minutes, you probably have a design issue)
    • General  dependency to having a developer around
      • Generic business logic code blocks can be written but a developer is required to insert the business logic on additional events
      • To view the all operations performed for an event, a developer needs to look at the code

So which model should you use?

I have used both models heavily on various occasions. For me personally, the decision on which one to use comes down to a project’s needs and a coding style preference. As an example, if you know you’ll have a lot of generic features and want to have reusable plugins, you are better off using the functionality based model. The same applies if you know there are processes that require to disable specific functionality on a regular basic. On the other hand, if you project is relatively small and includes simple business logic on a few events, the event based approach can be a good choice. Feel free to add feedback in the comment section if you see other pros and cons for each of these models or want to share experience in the area.

Advertisements

7 thoughts on “CRM Plugin Code Structure – By functionality or by event?

    • Hi Yawer, having plugins structured by event or functionality doesn’t makes a big difference IMO. When by event, you will filter the execution of business logic blocks based on the attributes present in the target entity. When you do functionality-based, the platform does the execution filter for you.

      If you have on operation that might exceed the 2 minutes execution timeout, it should probably not be in a plugin to begin with.

      Cheers

  1. I look at this among other things from the perspective of operations maintainability. In my opinion maintainability is one of the most important design considerations. If you consider the life of a typical system the initial developement effort is a relative blip on the timeline. A great application in theory may live on for years and will often continue to be modified. More often than not the team members working on that system will change over time and have varying degrees of skill. So if you look at this question of functionality versus event from an operations standpoint is the system harder or easier to maintain if functionality is broken down into pieces that can turned on and off with configuration or requires code to be manipulated and registered again in an elevation event? I would say anything you can do to enable team members to not have to change code is a gift to either your future self or people you may never meet. I often find that making a system more maintainable often increases my development complexity, but the dividends can pay off over years of support, upgrades and enhancements.

    • I don’t disagree with your reasoning. What I faced with the “functionality” based plugins (written with the idea of flexibility in mind) is that when you “disabling” a broken component (plugin step(s)), you are accepting that your system runs without some of its business rules. This could cause other issues. Is that more acceptable? The answer is always the same IMO : it depends…

      • I see where you are coming from. I wasn’t approaching the style from the perspective of something is broken so I need to turn it off. I’m looking at it from the standpoint of maintainability. Business logic separated into isolated components are easier to manage in place of new functionality. Over time business logic will most likely change or be enhanced in some way. Ideally this doesn’t involve ripping out what is already there but replacing and deprecating. If everything is baked into the code that process is more complex.

      • That is fair, Stephen. Although I have seen some crazy/nerdy developers structuring the code in ways that I felt was easy to understand. On implementations that require lots of coding, it has to be well though of. For smaller solutions, not having the greatest code structure can be acceptable (time investment vs value added…).

      • For sure. There are defiantly some fancy ways to create plugins and as you mentioned there are situations where functional style can make more sense. I’ve had some ideas on functionality style myself in the past. The thing that has lead me to my current philosophy over the last couple years is the single responsibility principle. I look at most design scenarios now from a micro-service style architecture including plugins. I’ve had the pleasure of debugging plugins written by others that were 10 screens of code that attempted to do a lot of things. In my mind if I had to choose between 2 plugins that performed 5 different responsibilities or 10 plugins that focused on a single purpose I would rather put in the extra work to create the additions plugins. The purpose of each would be more obvious (with proper naming conventions) and the amount of code in theory should be less in each. I also look at it from the perspective that who ever is on the operations side probably isn’t a highly skilled developer so making it more simple in that way is helpful for them. The challenge of course with the additional plugins is now you have more registrations to manage in your project which can be a pain. Fortunately that problem will be addressed soon enough.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s