A Simple Trigger Framework

Today I want to throw my hat into the Trigger Framework ring and present a simple one or, at least, a base starting one. There are many Apex Trigger Frameworks in the wild but most seemed too complicated for my day-to-day needs.

See my Introduction to Triggers if you don’t know what Apex Triggers are.

Overview

The framework uses the TriggerHandlerBase virtual class to handle dispatching to the correct “event” method such as “onBeforeInsert” and “onBeforeUpdate” in the derived handler class. One implements the derived handler class and overrides the desired event methods to keep the code simple and clean. To use the trigger handler, one instantiates it in the Trigger and invokes its run method. The trigger should define all the events so that if one needs to use that event in the future, one only has to override the event method in the handler class.

Trigger Handler Base

The base class does the heavy lifting of deciding which event method to invoke in the “Run” method. The event methods, beforeInsert, beforeUpdate, beforeDelete, afterInsert, afterUpdate, afterDelete, and afterUndelete, are virtual empty methods so that if one doesn’t need it, they simply do nothing. This is done so that an implementer doesn’t have to override the method like in many other frameworks.

The Run method passes in the appropriate records to each event method so that they can be easily used without having to use the Trigger context variable.

Account Trigger Handler Example

The Object Trigger Handler, such as the Account Trigger Handler shown here, needs to extend the TriggerHandlerBase and then override the desired event methods as needed. In each event method, downcast the List<SObject> to the appropriate List<[Object_Name_Here]> so that the records are more easily manipulated. Unfortunately, the current Apex compiler doesn’t let one do that within the event method’s List parameters automatically.

I prefer to use private methods and functions within the Object Trigger Handler to implement the desired functionality. Others recommend using a service class to implement the functionality.

Account Trigger Example

To use the Object Trigger Handler, instantiate it and call its run method.

Each trigger that uses this framework should specify all the events so that one only has to override the desired event method in the object trigger handler. This will cause Salesforce to potentially invoke the trigger unnecessarily but it’ll save implementation time in the future and there’s no noticeable impact to performance.

Benefits

  • Simple and easy to implement.
  • Doesn’t require implementing an interface for every trigger handler with lots of empty methods as seen in some trigger frameworks. Remember folks that an abstract or virtual class is another way of “Programming to an Interface”.
  • Handles the dispatching to the correct event method. This removes the spaghetti code found in many triggers.
  • Provides a base implementation that can be extended to add other features such as “Centralized Logging”, “Feature Toggling”, and “Recursion Management” within the Trigger Handler Base.

Limitations

  • Not sophisticated. There are other trigger frameworks that provide a lot more functionality and extensibility but are heavier to implement.

Other Frameworks & Resources