05 Mar 2022
In Salesforce Apex, you can loop over
Trigger.new as many times as you’d like.
Yes, you should only have one Apex Trigger per Salesforce object. Having redundant ones makes for an unpredictable runtime.
No, you don’t need to try to shove all business logic pertaining to a given Salesforce object into one single “trigger handler” Apex Class.
That’s a thing I actually used to do, when I first started writing Apex and was a new programmer.
In reality, it’s way more “modular,” and therefore simpler to maintain over the years, if you create a bazillion trigger handler classes per object, each of which perform their own
for loop over
It’s relatively computationally cheap to loop over
Trigger.new. Break up your trigger handlers into discrete clumps of business logic and don’t look back.
The amount of CPU time it takes to re-instantiate objects and variables is nothing compared to the amount of human time it takes to edit a messy codebase.
For starters, as a beginning developer in a small org, you can just invoke all classes for a given object back-to-back in your trigger. As your complexity starts to grow, refactor your handler classes to be compatible with a trigger framework and just call the framework from each trigger.
Or, if you’re an experienced programmer starting out in a greenfield org, just pick a trigger framework and write your trigger-handler Apex classes to conform to it from the get-go. You know what you’re doing, so you probably won’t find it too hard to structure your handler codebases so you can pick a different one and refactor later. Salesforce recommends Kevin O’Hara’s as a starting point, unless your org has NPSP or EDA installed, in which case you should piggyback onto the TDTM functionality written into those packages.
Separation of concerns
Also, if you follow Andy Fawcett’s principle of “separating concerns” and further splitting your trigger handler classes apart so that all of the interesting business logic is done in a standalone “application service layer” class that would be just as happy being invoked from a Lightning Web Component, a Scheduled Batch, etc. as it is being invoked from a trigger handler, then you’ll have an even easier time refactoring your trigger handler classes to conform to a different framework later, should you so choose.
Business logic should be encapsulated independent of how it’s invoked.
When you follow Andy’s concept, “what’s supposed to happen when the trigger runs” (application) logic goes in one Apex class, and “make the trigger run correctly” (trigger-handler) logic goes into another Apex class.
I found Andy’s Unit of Work pattern for DML to be far heaver weight than I needed, but the concept of breaking DML and the process of obtaining DML-ready SObjects away from any code covering “business logic” is something I found important in following Andy’s Separation of Concerns princple.
I ended up using Dan Appleman’s “Simple…Updater” pattern in his Pluralsight course with Don Robins, Play by Play: Adopting Trigger Design Patterns in Existing Salesforce Orgs (under “Trigger Patterns Without Frameworks” > “Combining DML Operations”).
FWIW, He demonstrated w/ an Apex class called
SimpleLeadUpdater, although I refactored his codebase into just
I’ll probably never publish this code because it’s too close of a variant on code that Dan seems to only have published behind a paywall. Sorry. I wish I could, because it was a bit of an intermediate skill to be able to translate what he’d done into a codebase I actually wanted to use, and it’d be neat to offer it to beginners, but it doesn’t seem ethical to do so. Maybe one day I’ll remember to see what he thinks. Or if you ever bump into him first and he thinks it might be a good idea to open-source, have him reach out to me.
Anyway, if you’re capable of doing that in Apex, or know someone who is, go check him out and pause the video to get some useful code that’s way simpler to implement than Andy’s Unit of Work, yet plays well with Andy’s other big ideas!
Pluralsight sometimes offers free weekends, usually on or a week away from U.S. long holiday weekends (Thanksgiving, MLK Day, Memorial Day, Independence Day, Labor Day). David Liu is very reliable about advertising them on Twitter and LinkedIn, or you can just watch Pluralsight’s home page and social media.