1

I have a few questions regarding best practices for the methods called from a trigger handler.

I am using a trigger handler that calls a method for some processing. I want to call the same method for a delete, update or insert. Is it a best practice to use if statements to check new and old lists for records. Then loop over the passed records and add a record id to a list. Than do the processing if the list is not null. I'm thinking this is less code that having different methods for insert, update and delete.

My second question is about updating data on a record. What is the best practice if I am updating a few different data points on the object that causes the trigger. For example, if I am updating an opportunity and I want to check a field and update the owner if certain conditions apply.. I also want to update some other fields on the opportunity. Do I create a separate method for each of those or should I have one method that updates all of the fields.

6
  • 2
    If you are creating the collection, you shouldn't have to check if it's null. Never return a null collection from your own code. – Adrian Larson Sep 26 '19 at 17:51
  • If I want to use the same method for insert, update and delete, I need to pass a null collection in some cases. So oninsert I'm passing a null old map. The other option is to create multiple versions of the method passing different variables. Thats what I am trying to figure out.. which is proper. Thanks for responding! – Frank Sep 26 '19 at 17:59
  • So it seems like the better option would be to create different methods for each (insert, update, delete) – Frank Sep 26 '19 at 18:24
  • There are trivial rules to know the category of event that is happening by looking at Trigger.old and Trigger.new (or the map equivalents). For example, both lists being non-null means it is "update". The old list being null means it is "creation". The new list being null means it is "deletion". (Both create and undelete fit in "creation", for example.) You certainly can provide a single entry-point for the trigger to invoke, but as each category of event typically needs different processing I would split out said processing into at least create, update & delete focused methods. – Phil W Sep 26 '19 at 19:01
  • Coding best practice, in general terms, is to use a number of small, focused methods, each concerned with one specific problem. If the inspection and updates in your object are quite unrelated I would consider splitting them into separate methods. You can then orchestrate their invocation with a higher-level (but still short) method. Note that some schools of thought see methods of more than 20 statements as too long. You can make your own decision. – Phil W Sep 26 '19 at 19:05
0

The pattern I favor is this:

trigger FscClaim on Claim (after update, after delete) {
    new MyHandler().handle(Trigger.old, Trigger.new, Trigger.operationType);
}

using this sort of handler class (instance methods or static methods as you like):

public class MyHandler {

    public void handle(Claim[] oldSobs, Claim[] newSobs, TriggerOperation op) {

        switch on op {
            when AFTER_UPDATE {
                afterUpdate(oldSobs, newSobs, ...);
            }
            when AFTER_DELETE {
                afterDelete(oldSobs, ...);
            }
        }
    }
}

The above uses the relatively recent switch and the relatively recent TriggerOperation enum value available via the Trigger Class context variables.

Or to apply a standard pattern to multiple types i.e multiple triggers call the same handle method:

public class MyHandler {

    public void handle(SObject[] oldSobs, SObject[] newSobs, TriggerOperation op) {

        // Common logic for all types...

        // ... and/or type specific logic
        String t = String.valueOf(newSobs.getSObjectType());
        switch on t {
            when 'Xyz__c' { ...}
            ...
        }
    }
}

And for trivial cases no handler class at all: start simple and refactor when needed. And always write tests for the trigger and not for the handler class: subtle difference exists and the handler class is an implementation detail only.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.