This idea is so frequently quoted that I wonder if sometimes it is being blindly followed without much thought. Here are some points in favor of triggers containing implementation code:
- Keeping the code in the trigger ensures its' (important) execution context - inside a trigger, before or after, insert or update etc - is clear.
- Always creating separate classes results in extra named (hard to name?) components that end up listed in profiles and deployment artifacts. More clutter, less cohesion.
- Note the advice usually isn't to create classes that represent the domain (and so are likely to be re-used) but to create utility methods that are less likely to be re-used particularly as their signatures have to include various trigger context variables.
- In any case the time to factor out code for re-use is when the need for re-use is discovered not before. Simple problems are best solved by simple solutions.
- Having test classes 1:1 with triggers is a simple to follow pattern.
So I suggest the advice should be: "A trigger is much like a method in a class and should have its logic factored out into other classes when it becomes unwieldy or violates the DRY principle".
Ok so I've answered my own question - I disagree. But I would like hear what others think...