Apex Triggers can lead to a more traditional pattern of if/then/else style coding, resulting in a procedural logic that is hard to maintain and follow. This is partly because they are classes and, as such, they don't naturally encourage breaking up the code into methods and separate classes. As we saw in the previous table, Apex Triggers are not the only execution context for Apex; others do support Apex classes and the object-orientated programming (OOP) style, often leveraging system-defined Apex interfaces to allow the developer to integrate with the platform, such as Batch Apex.

Apex has come a long way since its early introduction as a means of writing more complex Validation Rules in Apex Triggers. These days, the general consensus in the community is to write as little code as possible directly in an Apex Trigger, instead of delegating the logic to separate Apex classes. For a packaged application, there is no compelling reason to have more than one Apex Trigger per object. Indeed, the Salesforce security review has been known to flag this even if the code is conditioned to run independently.

A key motivation to move the Apex Trigger code into an Apex class is to gain access to the more powerful language semantics of the Apex language, such as OOP, allowing the developer to structure the code more closely to the functions of the application and gain better code reuse and visibility.