We can write apex classes in trigger body and these apex classes will be considered as inner classes as outer class will be trigger class/body. Is there any use case we can define classes in trigger body instead of defining it outside. Also what are the advantages of using trigger handlers(Ex. Modularity, use of future methods)? Please correct me if I have missed anything. Thank you.
Add a comment
|
1 Answer
If you adopt the Enterprise Patterns as defined by Andrew Fawcett, VP at SFDC and formerly CTO of FinancialForce, you will quickly realize the advantage of the underlying principle of separation of concerns into:
A trigger is merely an entry point to the domain layer and typically is coded as a single line of Apex.
Domains and Services invoke Selectors to fetch data; Services are orchestrated to do CRUD using Units of Work. This is all well explained in the Force.com Enterprise Architecture Book Second Edition (with rumors of a 3rd edition in the works)
What makes this pattern so especially useful beyond its software engineering underpinnings is its amenability to testing via dependency injection (as implemented by ApexMocks).
Ok, enough soap box; For me at least, inner classes in triggers break the pattern - it is putting logic in a place where it is not reusable, nor modularly unit testable. For quick-and-dirty SFDC orgs that are built without an eye towards architecture, they can certainly make coding triggers easier with fewer "files". But for orgs that grow into being "architected", you'll find you'll refactor these trigger inner classes out of existence.
