Pulling Code Out of Triggers

To date, triggers have only been accessible on each object's setup page, leading to a lot of hunting for code within the Salesforce CRM application. Even in Eclipse, switching between the Class and Trigger folders for a given project can be a pain.

These pains can partially be alleviated by keeping all Apex code in one place--as Apex Classes. With the addition of a consolidated trigger list in Summer09, some may feel that this post is superfluous, but consolidating code in one place, combined with the trigger list, will lead to a better development, debugging, and org administration experience.

First, here's a sample trigger (written by Jeff Douglas):

trigger AddOwnerColor on Account (before insert, before update) {

    // create a set of all the unique ownerIds
    Set<Id> ownerIds = new Set<Id>();
    for (Account a : Trigger.new)
        ownerIds.add(a.OwnerId);    

    // query for all the User records for the unique userIds in the records
    // create a map for a lookup / hash table for the user info
    Map<Id, User> owners = new Map<Id, User>([SELECT Favorite_Color__c FROM User WHERE Id IN :ownerIds]);   

    // iterate over the list of records being processed in the trigger and
    // set the color before being inserted or updated
    for (Account a : Trigger.new)
        a.Owner_Favorite_Color__c = owners.get(a.OwnerId).Favorite_Color__c;
}

Let's pull the code from the trigger into an Apex Class and leave a reference to that class & method in the trigger. We need to pass the list Trigger.new as a parameter to the new class's method:

The trigger:

trigger AddOwnerColor on Account (before insert, before update) {
AccountTriggers.AddOwnerColor(Trigger.new);
}

And the class:

public class AccountTriggers {
    public static void AddOwnerColor(Account[] accts) {

    // create a set of all the unique ownerIds
    Set<Id> ownerIds = new Set<Id>();
    for (Account a : accts)
        ownerIds.add(a.OwnerId);    

    // query for all the User records for the unique userIds in the records
    // create a map for a lookup / hash table for the user info
    Map<Id, User> owners = new Map<Id, User>([Select Favorite_Color__c from User Where Id in: ownerIds]);   

    // iterate over the list of records being processed in the trigger and
    // set the color before being inserted or updated
    for (Account a : accts)
        a.Owner_Favorite_Color__c = owners.get(a.OwnerId).Favorite_Color__c;
    } // close AddOwnerColor
}

While this may seem trivial, it has a few advantages:

• Easier to work in Eclipse (all code in the Classes section)
• Easier to write test code (can see tests and their associated methods in one place)
• Can promote code reuse by allowing other classes and triggers to call the same method.
• For those who like to include test code in the same class as the regular Class, this allows them to do so.

There's a catch (there always is):

You should comment into your Class which trigger is calling the class because otherwise, it is almost impossible to see at a glance where the code flows. This will especially help when writing and debugging tests.

Just a matter of personal style: It may be a good idea to write an Apex Class for each object's triggers (such as class AccountTriggers above). Code reuse is still possible, but it can track where triggers were originally used.

Happy coding!