Comments on: Pulling Code Out of Triggers

By: Auto-convert Contact-matching Leads : X-Squared On-Demand

Auto-convert Contact-matching Leads : X-Squared On-Demand — Thu, 11 Feb 2010 18:23:54 +0000

[...] the trigger. Note that I followed my own advice from Pulling Code Out of Triggers. (Other trigger classes have been [...]

By: Jeff Douglas

Jeff Douglas — Fri, 22 May 2009 21:21:12 +0000

David, thanks for taking my crappy code and making it better. I won’t receive a bill will I? I find your reasoning sound and have been refactoring a number of triggers in this same way.

By: Dave Manelski

Dave Manelski — Tue, 19 May 2009 01:40:01 +0000

We have a few classes with methods used by multiple triggers. In lieu of passing the trigger set (sObjects), we’ve opted for passing primivitive data types only between triggers and classes, purposefully to reduce dependencies. In your example, I would probably opt for passing a list of strings (for the Ids in the trigger set) and perform a SOQL in the class.

By keeping these dependencies to a minimum, you can easier package code, among other benefits. I’ve adopted this “best practice” based on observation and advice of more talented coders than myself so I’d be curious to find out how someone with formal computer science training weighs in on this.

By: David Schach

David Schach — Mon, 18 May 2009 20:37:57 +0000

I was just thinking about something similar today – with some logic and passing a String parameter, one could use the same class to update a single field to multiple values. For instance, an opportunity trigger to Account.Type -> Customer if total won opp value is >0, and -> VIP Customer if total won opp value > 250,000.
The possibilities are limitless!

By: Scott Hemmeter

Scott Hemmeter — Mon, 18 May 2009 20:11:41 +0000

I use this approach with a slight mod.

I have 1 trigger for each object and it fires for all events where I have code. Example of my Leads trigger below. It’s basically what you are suggesting, but it’s one common trigger and I add if/thens based upon the event that is firing.

This way there is 1 trigger and 1 class for each object.

trigger Leads on Lead (after insert, after update) {

// AFTER INSERT
if(Trigger.isAfter && Trigger.isInsert){
Leads l = new Leads();
l.CreateCampaignMembers(Trigger.new);
}

// AFTER UPDATE
if(Trigger.isAfter && Trigger.isUpdate){
Leads l = new Leads();
l.setOpportunityDefaults(Trigger.new, Trigger.oldMap);
l.transferOpptyFromLeadToAccount(Trigger.new, Trigger.oldMap);
}

}

By: Jeremy Ross

Jeremy Ross — Mon, 18 May 2009 17:11:55 +0000

I prefer to keep triggers very lean and free of business logic. I’d probably disagree with commenting your class with which triggers call it, for a few reasons. 1) The class shouldn’t know or care who calls it – the beauty of reuse, 2) someone will inevitably create a new client of the class and not update the “users” comment in the class, 3) this is related to 2, which is you’ll have a false sense of security of who is using the class.

The “show dependencies” button on the apex class screen would be infinitely more useful if it would show dependents instead of dependencies.