Chad Myers and Jeremy Miller have strong opinions on how ASP.NET MVC should work. They presented these opinions as a set of guidelines at last month's KaizenConf. Here are some highlights from Jeremy's summary.
At the core of their recommendations is a strong emphasis on limiting the power of Controllers. In their design, the surface area of Controllers is very data centric with inputs and outputs being limited to a single ViewModel each. By not exposing any aspect of HttpConext, the Controller can be more easily unit tested.
Not only are Controllers not exposed to HTTP artifacts, they should also be free of business logic.
Controllers should be thin. The only job of a Controller action is to translate the model coming in to the proper service calls and to create the output model object. All responsibilities for business logic are done by delegating to non-UI service classes. In other words, business logic does NOT go into a Controller.
Yes, that right. Under their plan MVC isn't everything, there is something beyond it to handle all the real work of data manipulation and storage.
There is a lot more to consider, but we are going to skip ahead to the issues surrounding HTML and JavaScript in the View layer.
Server side markup is never intermingled with client side JavaScript. It is our opinion that this all too common technique leads to unreadable code and eliminates the ability to TDD the client side JavaScript. This: callFunction(‘<%=Model.Variable%>’) is not allowed. If server side data needs to be passed to client side JavaScript, we do that by writing “var something = <% =Model.Variable%>.”
View’s should be very simple. If you’re using an if/then statement or some sort of looping expression, you’re doing something wrong. Conditional logic belongs in the Controller or in JavaScript libraries that can be tested with QUnit. No, or minimal, logic in the View’s reduces errors by moving logic out of hard to test code and into easier to test code – and yes, I’m declaring that JavaScript is easy to unit test. Tag Soup can be avoided. We tend to move looping constructs into our own partial implementation like: <%= this.RenderPartialForEachOf(m => m.Solution.Resolutions).Using<EditResolution>()%>. In that block of code, EditResolution refers to an ASCX control, and m.Solutution.Resolutions is a property of type IList<Resolution>. This statement will iterate over the list, and render a partial view for each Resolution object.