Moving the business logic out of Trigger functions and into dedicated "Trigger Handler" classes improves the application's design:

* the code is easier to test and maintain.
* it helps avoiding some bugs such as trigger recursion.

The Trigger functions should only dispatch calls to the corresponding Trigger Handler classes. See the links below for examples of Trigger Handler designs.


This rule raises an issue when a Trigger function contains one of the following syntax elements: loops, switch-case, try blocks, SOQL queries, DML queries, SOSL queries. The goal is to detect Trigger functions which have a complex logic. In practice method calls and if statements are enough to dispatch records for processing.


== Noncompliant Code Example

----
trigger MyTrigger on Account(after insert, after update) { // Noncompliant. The trigger is processing records itself instead of using a Trigger Handler.
    for(Account a : Trigger.New) {
        // ... 
    }
}
----


== See

* https://github.com/ChrisAldridge/Lightweight-Trigger-Framework[Lightweight Apex Trigger Framework]
* https://meltedwires.com/2013/06/05/trigger-pattern-for-tidy-streamlined-bulkified-triggers-revisited/[Trigger Pattern for Tidy, Streamlined, Bulkified Triggers Revisited]

ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

include::message.adoc[]

include::highlighting.adoc[]

endif::env-github,rspecator-view[]
