> I tend to disagree with the author's approach of pushing routine stuff out to the realm of "magically happens behind the scenes"
Me too, and it's easy to take this approach way too far to where you're basically recreating your own MVC architecture in some pseudo-service layer that you're not 100% sure how it even gets executed in the first place.
But I'll admit for things you should be doing on 99.9% of calls (e.g. validating the model) it's nice to have it done one place and one place only.
The drawback to validating the model in one place only, as shown, is that there is only one response for validation errors. Sure, it's got the details of the error that will vary, but it's ALWAYS sending a 400 error. Even the example of the 'usual' way includes a comment showing multiple possible responses:
// return bad request, add errors, or redirect somewhere
An ActionFilterAttribute might be a good approach, but in a real application I'd want two things: to apply it explicitly at the controller or method level rather than globally, and to pass it arguments to tell it what to do when there is an error. One of the arguments should allow me to call a response handler method, even if the only way to do that is to pass a string with the method name and use reflection to find and invoke it.
Me too, and it's easy to take this approach way too far to where you're basically recreating your own MVC architecture in some pseudo-service layer that you're not 100% sure how it even gets executed in the first place.
But I'll admit for things you should be doing on 99.9% of calls (e.g. validating the model) it's nice to have it done one place and one place only.