48 lines
1.6 KiB
Plaintext
48 lines
1.6 KiB
Plaintext
== Why is this an issue?
|
|
|
|
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
|
|
|
|
[source,apex]
|
|
----
|
|
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) {
|
|
// ...
|
|
}
|
|
}
|
|
----
|
|
|
|
|
|
== Resources
|
|
|
|
* https://web.archive.org/web/20210509202306/https://github.com/ChrisAldridge/Lightweight-Trigger-Framework[Lightweight Apex Trigger Framework]
|
|
* https://web.archive.org/web/20230130071426/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)
|
|
|
|
=== Message
|
|
|
|
Move the business logic to a separate trigger handler class
|
|
|
|
|
|
=== Highlighting
|
|
|
|
The Trigger function signature.
|
|
|
|
|
|
endif::env-github,rspecator-view[]
|