Over a period of time, a simple trigger can become very complicated as platform gets further customized with changing requirements. Apex Triggers are one of the essential features in achieving complex customization.
#Apex trigger code
For complex customization needs, those tools hit their limitation and development of code becomes essential. You can achieve quite a lot with those automation tools which are based on Salesforce’s philosophy of “With Click, Not Code”. Definitely worth a read.Salesforce’s Automation tools offers some non-declarative ways to customize. Meanwhile, kudos to Hari for a fine piece of work. Not only might this automate some of the “plumbing”, but conceivably bring us to that state of Nirvana where, with judicious use of some global interfaces, we might be able to control order of trigger execution across cooperating packages and between packages and Apex code on an organization instance.Īh well, one can dream. One can’t help but wonder if, now that we have a real tooling API, someone might come up with a client tool to generate and manage trigger handlers based on a framework like this…. NET platform (he does mention Java and C#), but the idea of dispatching by name is one we’ve seen in a number of Microsoft frameworks and languages. Our own framework doesn’t use that approach, for the obvious reason that it was built before Apex supported dynamic object creation by type, but it’s definitely worth considering for any design going forward. What really struck me was the innovative use of dynamic typing to instantiate objects based on the object type and name. As with our own framework, I don’t think it’s a solution for every scenario, but it does present a very elegant object oriented implementation to the problem. It’s beautiful piece of work (and I do appreciate the shout out). I was thrilled to see the other day a blog post by Hari Krishnan called “ An architecture framework to handle triggers in the platform”. So my goal in the book was to demonstrate the concepts involved, in the hope that others would build on it – come up with variations of different design patterns and frameworks based on those concepts.
I did this because I do not believe there is any one “right” trigger design pattern or framework for everyone and every situation. But the examples do reflect the concepts that our framework uses. The framework we use is considerably more sophisticated. Here’s a secret – the examples I used in the book do not, in fact, accurately reflect the framework I used in our own products. What I think I brought to the table was the idea that we could take advantage of the Apex language object oriented features to implement that concept in some really good, supportable and reliable ways. But I’m going to let you in on a little secret – what you find in the book isn’t really a “design pattern”, so much as a design concept.Īnd despite the chapter name “One trigger to rule them all”, I didn’t originate the idea that it was a good idea to control execution sequence by using just one trigger – experienced Apex developers already knew this. In my book Advanced Apex Programming, I spend quite a bit of time discussing trigger design patterns.
0 kommentar(er)
