28 lines
1.2 KiB
Plaintext
28 lines
1.2 KiB
Plaintext
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
|
|
|
|
* http://chrisaldridge.com/triggers/lightweight-apex-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]
|
|
|