Why is it a bad idea to write business logic in trigger. The organization that I work for asked me to move all the business logic in to apex class and call it in a trigger. Can anyone explain me why is that a best practice because it's the same logic.

  • 1
    Code reuse would be the primary reason.
    – Phil Rymek
    Feb 14, 2014 at 21:06

4 Answers 4


Once I implemented this pattern, http://developer.force.com/cookbook/recipe/trigger-pattern-for-tidy-streamlined-bulkified-triggers , I never looked back.

Why did I never look back?

because I knew that every trigger

  1. Would be implemented by the exact same structural logic
  2. That I had a consistent approach to bulkification using gateway classes to collect related records
  3. That I never had to worry about order dependency of multiple triggers on the same SObject
  4. That I could easily introduce exception handling and limits monitoring in a single place that would benefit all my triggers
  5. That I could readily introduce wrapper classes on my SObjects to do operations in an OO way; it also made it easy to implement services that might need invoking from triggers - controllers - REST services - I wasn't tempted into locking up the service logic within a trigger

It is seductive to code up simple business logic in triggers and you'll see many examples of such in various forums, but over time, it grows unwieldy. Take the plunge and you'll never regret it.

  • Thanks @crop1645 I need to understand how the handlers work.
    – cartman
    Feb 15, 2014 at 0:41
  • is this a question or an observation that you need to study the pattern in the aforementioned link a bit?
    – cropredy
    Feb 15, 2014 at 0:57
  • I need to study the pattern, not a question haha
    – cartman
    Feb 15, 2014 at 0:59

As a code base evolves and extends it becomes valuable to introduce layers of architecture, abstractions and certain patterns to your code. That is the goal, not just moving code out of your triggers for the sake of doing only that.

Organizing a code base should aim for better maintainability and re-use of business logic, the prevention of bugs, easier debugging, separation of responsibilities, replace-ability by abstraction, and much more.

This is why many developers/companies use some sort of custom apex trigger framework, or even more advanced code architecture. There is an excellent blog about these things on the developerforce website by Andrew Fawcett: Apex Enterprise Patterns - Separation of Concerns

  • 2
    To add onto Samuel's comment, using Trigger handler patterns is one way of forcing your code to execute in a certain order, under certain criteria. If you have several triggers on the same object, for instance, it makes it very difficult to digest which operations happen at which time. Feb 14, 2014 at 21:20
  • Thanks Samuel and James, Code reusability and Maintainability are not the exact answers I am looking for. Thanks for providing me the link to the blog.
    – cartman
    Feb 15, 2014 at 0:40

Code organization should not be overlooked. Just because your code works does not mean that it is complete, in my opinion. As your codebase grows, code entropy also increases, which down the line means what should have been a trivial change may end up taking days to complete and test.

This doesn't apply to just Apex code, but to any language you are coding in. I would suggest picking up the book Clean Code to get a good primer and start you on your journey to writing, as the book says, clean code.


Because trigger is hard to understand when you have much logic there. In my opinion trigger is place to manage methods and class is place to store them

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.