For some reason I just kept wanting to say, "Trigger Handler Framework" in this video... It's just a "Trigger Framework". I'm sorry my brain just couldn't stop feeding me those words. It's just a Trigger Framework.
Thanks, super helpful to see these practices in action. I was given one sample trigger framework before and it had way too many layers of abstraction. Looking forward to more videos like this!
Aiight, first of all, thank you for your content! It's of the highest quality compared to the competition in regards to both topics and delivery. I want to discuss the "Why?" points because I was asked this at an interview, and didn't answer so great repeating the usual stuff that's listed on the web on this topic. So here's my 5 cents. 1. "If you put your logic in the trigger, it becomes hard to unit test that logic." I'm on the fence about this. I don't really have a good argument for it, but I'd rather test DML operations and not trigger handler methods. Kinda because it's closer to the actual use case. As for helper methods - you can use them inside the trigger, with no handler class as a mediator. So there's no difference in that regard whether you put your logic inside the trigger or not, it's a matter of how you organize your tests. 2. Reusability. I find this unrelated. Again, put the reusable parts in helpers/utilities and reference them right inside the trigger. No difference whether you're using a handler or not. 3. Readability (nice, modular, beautiful-looking code). Yep. No objections. What I don't see mentioned is by using a handler inside a trigger you get to choose system vs user mode. Trigger always executes in system mode, while you can write a with sharing handler, and that's easily an equally important reason as reusability and readability in my opinion.
I tend to use isBefore if I want to make direct updates to the record that initiated the trigger. I use isAfter if I want to do something to other records (child records, parent records, completely unrelated records).
You can very easily add that to this framework. In fact I have a version of the code that does it in about 5 lines of code if you are interested. I actually prefer utilizing custom settings for this instead of custom metadata (if you're talking about turning the trigger on and off by flipping a switch or based on a running user). I have a video explaining why I prefer custom settings if you're interested: ua-cam.com/video/eoTi_SQUjp4/v-deo.html&ab_channel=CodingWithTheForce
To further elaborate on the question though. This framework is just super simple and easy to understand and it's also very flexible. I've tried using 5-6 different frameworks and this one was the easiet to implement, the easiest to teach developers, allowed me to easily add whatever I needed and it gave me all the core benefits of a typical trigger framework.
Very cool. I will look into this for my own projects. Have you ever used a Logger Framework? Logging has been a pain point with Salesforce and I've wondered if Logger Frameworks could help.
Thank you so much! I definitely have investigated them. This is my favorite logger framework personally, I plan to do a video on it eventually, but it is excellent and makes life quite a bit easier when logging: github.com/rsoesemann/apex-unified-logging
The Trigger Framework is perfect for a use case I'm facing. Is there a similar concept of a Validation Rules Framework that I can use to bypass Validation Rules?
Hey, I’m sorry for the late response, I must’ve missed this comment somehow. You can actually use this exact same tactic to create validation rule switches. In fact, I think (maybe) at some point I briefly mention that in the video. Here’s a pretty good article explaining how to achieve that in validation rules: salesforceprofs.com/hierarchy-custom-setting-in-validation-rules/
@@CodingWithTheForce not late at all! I watched the video when you first released it and have a need for it now. Thanks for the validation rule suggestion, I will try that out.
What if in a scenario where you want to do something in both after insert and after update? would you need to override both afterInsert() and afterUpdate() in the handler?
@@clydetan7731 If you wanted to do that, what I would suggest is making another virtual method in the TriggerHandler class called "AfterActions" or something and have it called in the run method for both afterInsert and afterUpdate triggercontexts. Then you can override that virtual method in your class and only call it instead of the individual afterInsert or afterUpdate methods. Hopefully that makes sense.
For some reason I just kept wanting to say, "Trigger Handler Framework" in this video... It's just a "Trigger Framework". I'm sorry my brain just couldn't stop feeding me those words. It's just a Trigger Framework.
Thanks, super helpful to see these practices in action. I was given one sample trigger framework before and it had way too many layers of abstraction. Looking forward to more videos like this!
Why dont you make a video for how we can use OOPs concepts in apex and best practices in apex with live examples
That’s a great idea! I will definitely add it to the list. Thanks Ashutosh.
Aiight, first of all, thank you for your content! It's of the highest quality compared to the competition in regards to both topics and delivery.
I want to discuss the "Why?" points because I was asked this at an interview, and didn't answer so great repeating the usual stuff that's listed on the web on this topic. So here's my 5 cents.
1. "If you put your logic in the trigger, it becomes hard to unit test that logic." I'm on the fence about this. I don't really have a good argument for it, but I'd rather test DML operations and not trigger handler methods. Kinda because it's closer to the actual use case. As for helper methods - you can use them inside the trigger, with no handler class as a mediator. So there's no difference in that regard whether you put your logic inside the trigger or not, it's a matter of how you organize your tests.
2. Reusability. I find this unrelated. Again, put the reusable parts in helpers/utilities and reference them right inside the trigger. No difference whether you're using a handler or not.
3. Readability (nice, modular, beautiful-looking code). Yep. No objections.
What I don't see mentioned is by using a handler inside a trigger you get to choose system vs user mode. Trigger always executes in system mode, while you can write a with sharing handler, and that's easily an equally important reason as reusability and readability in my opinion.
Thank you very much for all your videos. They are very helpful.
Great video as always! I still have this confusion, in which scenarios to use Trigger "isBefore" and "isAfter"
I tend to use isBefore if I want to make direct updates to the record that initiated the trigger. I use isAfter if I want to do something to other records (child records, parent records, completely unrelated records).
Thank you !
Any reason you prefer this framework over one that uses a Custom Metadata setting to control the execution of Apex?
You can very easily add that to this framework. In fact I have a version of the code that does it in about 5 lines of code if you are interested. I actually prefer utilizing custom settings for this instead of custom metadata (if you're talking about turning the trigger on and off by flipping a switch or based on a running user). I have a video explaining why I prefer custom settings if you're interested: ua-cam.com/video/eoTi_SQUjp4/v-deo.html&ab_channel=CodingWithTheForce
To further elaborate on the question though. This framework is just super simple and easy to understand and it's also very flexible. I've tried using 5-6 different frameworks and this one was the easiet to implement, the easiest to teach developers, allowed me to easily add whatever I needed and it gave me all the core benefits of a typical trigger framework.
Very helpfull thank so for the help
Very cool. I will look into this for my own projects.
Have you ever used a Logger Framework? Logging has been a pain point with Salesforce and I've wondered if Logger Frameworks could help.
Thank you so much! I definitely have investigated them. This is my favorite logger framework personally, I plan to do a video on it eventually, but it is excellent and makes life quite a bit easier when logging: github.com/rsoesemann/apex-unified-logging
That is awesome. Thanks so much,Sir.
The Trigger Framework is perfect for a use case I'm facing. Is there a similar concept of a Validation Rules Framework that I can use to bypass Validation Rules?
Hey, I’m sorry for the late response, I must’ve missed this comment somehow. You can actually use this exact same tactic to create validation rule switches. In fact, I think (maybe) at some point I briefly mention that in the video. Here’s a pretty good article explaining how to achieve that in validation rules: salesforceprofs.com/hierarchy-custom-setting-in-validation-rules/
@@CodingWithTheForce not late at all! I watched the video when you first released it and have a need for it now. Thanks for the validation rule suggestion, I will try that out.
very helpfull
What if in a scenario where you want to do something in both after insert and after update? would you need to override both afterInsert() and afterUpdate() in the handler?
I mean, that's going to be 2 method in 1 class calling the same logic from a utility class. Or is there any way to do it in a single override method?
@@clydetan7731 If you wanted to do that, what I would suggest is making another virtual method in the TriggerHandler class called "AfterActions" or something and have it called in the run method for both afterInsert and afterUpdate triggercontexts. Then you can override that virtual method in your class and only call it instead of the individual afterInsert or afterUpdate methods. Hopefully that makes sense.
@@CodingWithTheForce thank you