It has been a while since I wrote a blog for my readers but Ive been working hard in developing a framework to improve your organisations in a big way.
I decided to turn my attention to triggers. There are many well published trigger frameworks and all have merits in that they improve the manageability of code, correctly orders execution, however as with everything good technologists will continually evolve a model. I was impressed with Tony Scotts http://developer.force.com/cookbook/recipe/trigger-pattern-for-tidy-streamlined-bulkified-triggers pattern as it simplifies the trigger.
Independent to Hari Krishnan https://krishhari.wordpress.com/tag/apex-trigger-design-pattern/ I too noticed some room for improvement because Tony’s framework would require continual adaption of the TriggerFactory for every new trigger that is developed. The solution that I came up with was basically the same as Hari.
However, I was concerned that all frameworks to date have only been designed to solve the old problem of code manageability and order of execution, but I always incorporated far more into my frameworks, notably the following additional features:
1. Trigger Control
3. DML Consolidation
We will later explore these 3 facets of the framework in more detail. Lets first of all have an overview of the building blocks of the framework
The classes in Red make up the baseline of the framework. These classes do not need to be changed. The classes in Blue are classes that will be created for each Trigger. You can create as many "Logic" classes as you wish depending on the number of separate business areas and complexity of codebase in your organisation. The "Account Helper" class is also optional, this just aids the Logic classes and provides better modularised code.
Of course we must have the starting Trigger as well, shown as "AllAccountTrigger" above.
In the next blog I will go into details of each class.