5

When working on an org with a few simple requirements for triggers, I feel that using a trigger framework easily bloats the code base and a bit overkill as well. I admit this is short-sighted as requirements change in time, but until then, I feel there's very little reason to use a framework. Not to mention, customers with smaller orgs tend to have stricter time & cost restrictions.

When should a trigger framework be applied? Are there other factors that determined a framework's necessity?

7

I think a Trigger Framework is necessary in all but the simplest of orgs. As soon as you have two separate requirements for the same object, then go to a trigger framework. I definitely agree with dphil that eventually they are necessary, so just bite the bullet and go for it.

By using a framework, you can gain several benefits including:

  • Recursion Control
  • Order of Execution Control
  • Inclusion of switches to control firing of triggers, methods

The hard part is deciding what framework will work for you. I've been using the TriggerX pattern with success in my org. Once you've gained an understanding of how to code against it, it isn't any slower than writing your own triggers. There are a 1000 ways to implement a framework, so you may prefer something else.

  • Would you know if trigger frameworks are necessary in the context of a dev501 programming assignment, considering the requirements will never grow? – jmrjulian Oct 8 '14 at 21:04
  • 2
    I would say that is your choice. I haven't taken the exam yet, but it is my understanding that they are looking more at ability to meet requirements and not do dumb things like put a SOQL query in a for loop (which can be easy to do in a trigger). You also have the essay at the end in which you can explain your rationale for doing what you did. – Daniel Hoechst Oct 8 '14 at 21:09
  • A trigger framework is specifically going to not be allowed in the 501 exam. – ca_peterson Oct 9 '14 at 2:38
  • Interesting, I guess that makes sense since you probably didn't write the code. – Daniel Hoechst Oct 9 '14 at 2:43
  • @ca_peterson what if you write it yourself during the assignment period? Is it the framework itself or the pre-written code or pre-written-by-someone-else code that's the problem? – Dominic Oct 9 '14 at 6:53
2

You should always have some sort of Trigger framework in place. Sure it might shave off a couple of hours, but later on when you add more on, 1 of 2 things happen:

1) You build bloat on top of more bloat and it gets hard to debug and add to which takes up additional time + money.

2) You revamp all of the Triggers and put them into your framework.

Either way down the road it will take much longer and for what? You really only shave off a couple of hours of work.

There are plenty of ways to have a sort of minimized framework for your triggers. One such example that I sometimes use:

trigger AccountTriggers on Account(before insert, before update, before delete, after insert)
{
  //This method allows you to have a single Trigger for an object.
  //You can easily find anything that would be fired off a particular object by putting them
  // all in one spot.
  if (Trigger.isBefore && Trigger.isUpdate)
  {
     UpdateCountryTH.updateCountry(Trigger.new);
  }

  //You can see here that the different times the trigger is fired is clearly separated out.
  //It makes it really easy to see what fires at what time.
  if (Trigger.isBefore && Trigger.isInsert)
  {
    UpdateCountryTH.updateCountry(Trigger.new);
    UpdateChildNameTH.updateName(Trigger.new, Trigger.oldMap);
  }
}

Doing work in a Trigger helper:

public class UpdateCountryTH
{
  //You can easily identify the single thing this helper is created to do.
  //Separating all of these out to their own particular places eliminates a lot of bloating confusion
  //and makes it extremely simple to add more helper classes like this.
  public static void updateCountry(List<Account> triggerNew)
  {
    //do work
  }
}

Other non-related work from the first thing in the trigger.

public class UpdateChildNameTH
{
  public static void updateName(List<Account> triggerNew, Map<Id, Account> triggerOldMap)
  {
    //other work here
  }
}

As you can see, you can build an extremely simple framework that can still prevent your code from getting large and bloated to keep it manageable. Not everyone is going to agree with this style, but honestly adding something this simple is even a major help.

EDIT: Due to request...

The benefit here is that the actual logic your trigger needs to work on can be extracted out to other classes. When you do this, you don't have a single file trying to do a ton of things at once. You can clearly identify the different parts of the trigger and with proper naming you can easily find a trigger you are looking for and then easily focus on just that single part.

  • 1
    Your example adds 6 lines of code (around the "do work"), an extra component (the class), and an extra level of indirection. At first sight that looks like a larger and more bloated solution. Can you be more specific about the benefits? – Keith C Oct 8 '14 at 19:35
  • @KeithC Well, hopefully that didn't just make it more confusing... – dphil Oct 8 '14 at 20:40
  • Yeah being able to name the operations - and break complicated operations up into multiple methods - I buy as a benefit. – Keith C Oct 8 '14 at 21:06
  • 1
    A possible disbenefit of this pattern is that you may get into a situation where for instance UpdateCountryTH.updateCountry and UpdateChildNameTH.updateName are querying the same objects, in separate queries. As more and more methods are added, SOQLs are being used up readdressing the same objects in each method. Running out of SOQLs is the biggest trigger issue we have in a couple of orgs. Can be helped by using statics to hold query results. – Dominic Oct 9 '14 at 6:21
  • @Dominic Sure that's definitely true. The main benefit I was touting with this framework is the ease of implementation (since their concern was spending extra time using a pattern) and also simplicity. Essentially a minimalist framework. – dphil Oct 9 '14 at 13:41
0

Technically obviously its not necessary. Its all about how maintainable you want your code to be. Its a style choice, but if I was a coworker of yours I'd prefer you always used one for sure!

Having said that, I think if the trigger is performing one simple action its probably not necessary, but anything beyond that and I'd move the logic into a class out of the trigger. Like you said though its almost inevitably going to happen in the future so you might as well just do it now.

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.