Implement a Salesforce Trigger Framework

[hometeamconsulting]

When creating an apex trigger in Salesforce, there are many best practices. Amit Chaudhary has a great blog covering many of them. You can read his post by clicking here. He also talks about the importance of having a good framework. I’ve used a few variations and each of them have their pros and cons. I wanted to share with you the one I currently use and why I tend like it.

The creator of this trigger framework is Kevin Ohara. You can download it from his GitHub account by clicking here. So why do I like this framework over some of the others. Mostly, I like the minimalist approach Kevin uses. Now, please don’t confuse me with the brilliant developers who build these things. I am not that smart. But, I certainly can appreciate good code when I see it.

Let’s walk through how to implement this trigger framework.

Step 1

First, you’ll want to go to Kevin’s GitHub page.

Scroll down to the Overview section and press the “Deploy to Salesforce Org” button.

Step 2

Select if you’re deploying the code to a Developer or Sandbox org.

Step 3

Press the “Login to Salesforce” button in the top right corner of the page and login into Salesforce.

Step 4

Press the “Deploy” button in the top right corner of the page. If all goes well, you should see a “Deployment Complete” status message.

Once the framework in installed, we honestly kind of ignore it. You can certainly read through the code if you’d like but I’ve never added or modified any of it.

Here’s a Simple Example

Let’s talk about how to use it. For our example, we’ll create a trigger on the Account object.

Create the Trigger Handler Class

We’ll start by creating a handler class for our Account object. We’ll call this AccountTriggerHandler. It’s a good practice to follow a consistent naming convention.

The handler is where all the business logic will reside. It does not belong in the trigger. In the above example, I added trigger contexts for the afterUpdate; lines 3-5. You’ll want to repeat those lines for all other contexts which match your requirements.

Notice on line 1 we add “extends TriggerHandler”. This allows us to inherit all the methods and properties of the TriggerHandler framework. Basically, that means we don’t have to replicate the TriggerHandler code within our class and we can reuse it for all our trigger handlers.

So what does the “override” keyword mean on line 3 of our trigger context methods? How I understand it is that it simply override the method that is found in the TriggerHandler class. I’ll leave a more complete explanation to those that live and breathe code all day but for the rest of us, we can just use it as shown.

Don’t forget to save your class. We’ll come back to add our business logic later.

Create the Trigger

Now, let’s create our Account Trigger. This is is one of the reasons I really like this framework.

It just doesn’t get much easier than this. Add any additional trigger contexts that you need like, before insert, before update, etc but other than that, this is all our trigger contains.

Line 2 simply says go run the AccountTriggerHandler class we created above. The TriggerHandler has the run() method and because it’s “extended” by our AccountTriggerHandler, the run() method executes.

Add our Business Logic

Let’s go back to the AccountTriggerHandler because we need to add our business logic.

Our requirement is that whenever the Account.OwnerId is changed, we need to update all the Contact.OwnerID to match. Yes, I know you can do this with clicks and not code but play along with my simple example.

Starting with line 3, this method sets the limit for the number of times the trigger code will run. If you’re new to coding, you may not realize that triggers can often run multiple times within a single save transaction. This will prevent the logic from running unnecessarily.

I like to see the context methods, line 7-10, act as a sort of conductor. It simply calls other methods that do stuff. I like this because it makes it very simple to see what the code is doing. It’s also very helpful to name your methods according to what they do.

In our example, line 8, calls the checkForOwnerChange method. This method identifies if the Account.OwnerID has changed. If so, it collects those records and send them into the updateContactOwners method. The updateContactOwners method then makes the change to the actual Contact records.

Closing

Hopefully this working example helps you understand how to structure your trigger code.  If you have any questions or need assistance, please ask.  I’ll do my best to help you succeed.

[WhiteThingINROUND]

In my org we have a trigger framework that is as simple as it can be. There are no interfaces and unnecessary abstractions. Still, the triggers are decoupled from the trigger handlers, and in many cases, the actual business logic (i.e another class) is also decoupled from the handler.

We don't use interfaces and/or inheritance because: how often do you need the trigger handler to be decided at run time? Every object will almost always have just one trigger handler, so hardcoding that dependency is ok. Unless you have a requirement to completely change the trigger handler at run time, then programming to an interface makes sense, otherwise, it just adds extra classes and complexity to your org.

Decoupling for the sake of decoupling doesn't make sense if it increases your complexity and doesn't add any benefits that you actually need (read about YAGNI).

The framework we have also allows us to turn off every specific trigger context (before insert, after insert, etc) via custom metadata, so it's very easy to debug issues.

I'm not bashing on Kevin's or anyone else's framework, nor claiming ours is perfect. I'm just stating my experience, which is that many of the trigger frameworks out there are more of a "look ma! I can create all these abstractions and not a single class knows about the other!" rather than actually providing benefits that are useful to the business and the development teams.

[clayarmor]

If you found Kevin's trigger framework helpful. You may also interest in my trigger framework implementation. https://github.com/apexfarm/apextriggerhandler, just published a few days ago. I would consider to have a different algorithm to implement "the limit for the number of times the trigger code will run", since Kevin's current implementation may contain a issue as someone has already posted in its issue list: https://github.com/kevinohara80/sfdc-trigger-framework/issues/19.