why we are create handler class of trigger in salesforce?

Question

If we can create trigger and we can write all code in trigger so why we need to create handler class of trigger?

Answer 1

It may seem fine to do that at first, and honestly it is. But as your org grows and matures there are several reasons to separate the logic out of your triggers and have the trigger delegate the logic to a handler class. I have run into orgs where there are multiple triggers on one object (which is obviously not good). As well as triggers that started out as something simple then over time grew into a monstrosity of a logic mess.

Another reason is it makes them easier to test.

From Trigger Frameworks and Apex Trigger Best Practices by Kevin O'Hara:

Trigger Best Practices

Logic-less Triggers

Another widely-recognized best practice is to make your Triggers logic-less. That means, the role of the Trigger is just to delegate the logic responsibilities to some other handler class. There are many reasons to do this. For one, testing a Trigger is difficult if all of the application logic is in the trigger itself. If you write methods in your Triggers, those can’t be exposed for test purposes. You also can’t expose logic to be re-used anywhere else in your org. Good old OO principles tell us that this is a bad practice. And to top it all off, cramming all of your logic into a Trigger is going to make for a mess one day. To remedy this scenario, just create a handler class and let your Trigger delegate to it.

...

Why Use a Framework?

So now that we have some best-practices out of the way, we can talk about frameworks and why we would want to use them. At this point you might be asking, “if I follow best-practices, do I really need a framework”? The short answer is no, you don’t need always need a framework to write your Triggers. A framework may, however, greatly simplify your development efforts when your code base gets large. In a nutshell, your framework should have the following goals:

• Help you to conform to best practices
• Make implementing new logic and new context handlers very easy
• Simplify testing and maintenance of your application logic
• Enforces consistent implementation of Trigger logic
• Implement tools, utilities, and abstractions to make your handler logic as lightweight as possible

I have been using sfdc-trigger-framework for a couple of years, and I will not allow triggers to go into an org I am responsible for without utilizing some sort of trigger framework.

This provides a few extra bells and whistles as well. One of my favorites is the ability to bypass a trigger. For example; If I have a piece of code I am testing and it is firing off a trigger that already has the handler logic tested I don't need to test it again. So I can bypass it and test what is at hand rather than setting up all my data to satisfy what I am needing to test as well as satisfying the trigger handler logic again.