Salesforce Automation Solutions: Reinforcing Apex Trigger Best Practices with the help of 2 popular Salesforce Trigger Frameworks

Posted by Niraj Wani
June 18th, 2018

Salesforce’s Automation tools offers some non-declarative ways to customize. You can achieve quite a lot with those automation tools which are based on Salesforce’s philosophy of “With Click, Not Code”. For complex customization needs, those tools hit their limitation and development of code becomes essential. Apex Triggers are one of the essential features in achieving complex customization. Over a period of time, a simple trigger can become very complicated as platform gets further customized with changing requirements.

Benefits of Apex Trigger Frameworks

Apex Trigger Frameworks provides a structure that allows easy maintenance and enforcement of best practices. Implementing Trigger Framework can reduce your development lifecycle. One of the best practices is to use a single trigger per object. It reduces clutter and provides easy maintenance and control. In a larger team environment, it provides single code base to work on making it a lot easier to write test classes.

Another best practice is to make your Triggers logic-less. The role of the Trigger is just to delegate the logic responsibilities to some other handler class, in order to avoid future mess.

We will look at two popular trigger frameworks that will help you maintain the best practices and also make good use of the defined structure they provide.

Framework 1: Tony Scot’s Trigger Patterns – Trigger Pattern for Tidy, Streamlined, Bulkified Triggers

This framework utilizes an interface, Trigger Handler class and a factory class

Benefits of this framework are as follows:

  • Avoiding repetitive SOQL queries which can potentially hit governor limits
  • Keeping code tidy and maintainable with single trigger per object
  • Keeping trigger bulkified avoiding unnecessary SOQL and avoiding problems with multiple trigger contentions

Here, we will look at bits of code to understand how framework operates.

Your trigger will look like a one line of code, as given below:

trigger AccountTrigger on Account (after delete, after insert, after update, before delete, before insert, before update)
{
TriggerFactory.createHandler(Account.sObjectType);
}

TriggerFactory class is used to instantiate Trigger Handler associated with a particular sObject. TriggerFactory class’ execute method is called, and in turn call to handler’s methods will happen at appropriate trigger events.

Handler class will need to implement interface ITrigger as shown in below line.

public with sharing class AccountHandler implements ITrigger

ITrigger interface makes it mandatory to implement certain methods and these methods provide a structured way to write trigger code. For example, bulkBefore method is called prior to execution of BEFORE trigger and can be utilized to cache any data into maps. Method beforeInsert is called iteratively for each record to be inserted during a BEFORE trigger, it is recommended not to execute SOQL in this method.

Below is the list of methods that structures the code within handler.

Methods that are meant for caching data before processing:

  • bulkBefore
  • bulkAfter

Methods that gets called iteratively in trigger loop:

  • beforeInsert
  • beforeUpdate
  • beforeDelete
  • afterInsert
  • afterUpdate
  • afterDelete

Below method is called once all records have been processed by the trigger. Use this method to accomplish any final operations such as creation or updates of other records.

  • andFinally

Framework 2: Kevin oHara’s SFDC Trigger Framework

This framework provides a base class called TriggerHandler which includes context-specific methods that are automatically called when a trigger is executed.

Below is an example of Account Trigger Handler

public class AccountTriggerHandler extends TriggerHandler {

You will need to override methods in your handler for which you want trigger to execute custom logic.

Below is sample code in Account Trigger handler which overrides method beforeUpdate and will have code to handle trigger logic.

public class AccountTriggerHandler extends TriggerHandler {

public override void beforeUpdate() {
for(Account act : (List<Account>) Trigger.new) {
// code to handle beforeUpdate
}
}

// add overrides for other contexts

}

Here are all the methods that you can override in handler:

  • beforeInsert()
  • beforeUpdate()
  • beforeDelete()
  • afterInsert()
  • afterUpdate()
  • afterDelete()
  • afterUndelete()

To call the trigger handler from trigger, all you need is to construct an instance of trigger handler and call the run() method. Here is an example of the Opportunity trigger.

trigger AccountTrigger on Account (before insert, before update) {
new AccountTriggerHandler().run();
}

Conclusion:

Kevin oHara’s SFDC Trigger Framework is easy to implement. Tony Scot’s Trigger Patterns provides separation of logic for bulkification with methods bulkBefore(), and bulkAfter(). Both trigger frameworks make writing and maintaining triggers easy and also ensure alignment of with best practices.

Comments (0)