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.
/filters:no_upscale()/sponsorship/topic/25afca57-6bcb-4c42-9a70-fbea10ce4fc7/MicrosoftLogoRSB-1678874949003.png)
/articles/dotnet-spa-templates-proxy/en/smallimage/ASP-NET-SPA-templates-proxy-changes-small-1683016303172.jpg)
/presentations/net-apps-cloud/en/smallimage/infoq-live-logo-small-1683100880551.jpg){kind=logo}
/articles/asp-dotnet-minimal-apis/en/smallimage/logo-1678972581766.jpg){kind=logo}
/articles/functional-dotnet-development/en/smallimage/Fsharp-vs-Csharp-is-one-more-functional-than-the-other-small-1676023056578.jpg)
/articles/dotnet-grpc-json-transcoding/en/smallimage/logo-1674822319367.jpg){kind=logo}
/articles/Dotnet-Seven-MSMQ-Alternatives/en/smallimage/logo-1670585778128.jpg){kind=logo}
/minibooks/jhipster-mini-book-7/en/smallimage/logo-1677849630224.jpg){kind=logo}
/presentations/organizations-evolve-work/en/smallimage/Jennifer Davis-s-1681717407074.jpg)
/presentations/secure-microservices/en/smallimage/Stefania Chaplin-s-1674204811056.jpg)
/articles/delivering-fast-testing-strategies/en/smallimage/deliver-fast-tests-have-to-last-small-1685548178496.jpg)
/articles/eda-mediator/en/smallimage/event-driven-architecture-with-mediator-topology-small-1685547200315.jpg)
/articles/azure-functions-quarkus/en/smallimage/azure-functions-on-quarkus-3-1685542580748.jpg)
/minibooks/architecture-2023/en/smallimage/logo-1685600892155.jpg){kind=logo}
/presentations/lyft-cd-benefits-challenges/en/smallimage/tom-wanielista-small-1685002834068.jpg)
/presentations/green-software-growth/en/smallimage/Marco-Valtas-small-1685609473905.jpg)
/articles/test-automation-ci-cd/en/smallimage/effective-test-automation-approaches-for-modern-CI-CD-pipelines-small-1685355310638.jpg)
Community comments
That should be obvious
by Francois Ward,
Re: That should be obvious
by Jonathan Allen,
Re: That should be obvious
by Francois Ward,
Re: That should be obvious
by Chris Pellett,
Re: That should be obvious
by Francois Ward,
Why was the words opinions in the title?
by Jeff Santini,
Re: Why was the words opinions in the title?
by Jonathan Allen,
That should be obvious
by Francois Ward,
Your message is awaiting moderation. Thank you for participating in the discussion.
MVC is a pattern for the UI, not for the application as a whole. So of COURSE they should be free of business logic. If you have a 3 layer app, the MVC layers are "sub layers" of the UI layer. The model is just the result of speaking to the business layer (or some other mechanism). If you see it that way, then it all fals into places.
Why was the words opinions in the title?
by Jeff Santini,
Your message is awaiting moderation. Thank you for participating in the discussion.
In reading the infoq article the opinions I see expressed are classic interpretations of MVC. Personally, I have never heard a credible opinion that contradicts these.
This is not to say it is not worth repeating as Jeremy and Chad have done, but to ask why you title the article "Chad Myers and Jeremy Miller: Opinions for ASP.NET MVC Developers" rather than "How to do MVC in ASP.NET".
Who is contradicting them?
Re: Why was the words opinions in the title?
by Jonathan Allen,
Your message is awaiting moderation. Thank you for participating in the discussion.
Jeremy titled his piece "Our “Opinions” on the ASP.NET MVC (Introducing the Thunderdome Principle)" and was very presisent in calling his design guidelines "opinions". Likewise, he kept refering to Ruby on Rails' philsophy of "Opinionated Software".
Re: That should be obvious
by Jonathan Allen,
Your message is awaiting moderation. Thank you for participating in the discussion.
Unless I am very mistaken, that is not obvious at all to most developers with a ASP or ASP.NET/WinForms background. Having sub layers of the UI layer in addition to all the other layers is just something that wouldn't occur to many of them.
Re: That should be obvious
by Francois Ward,
Your message is awaiting moderation. Thank you for participating in the discussion.
The reason it may not be obvious, is because of the mixup in the terminology. Devs in the microsoft ecosystem are always hammered with talk of "3 tier architecture" (tiers being -physical-, not logical, separations), which, while not the end all be all, is fairly valid.
Then there's all the people who learned about it ad-hoc hammering them with 3 layer architectures (which is basically only sufficient for small prototypes or minimalistic applications), under the guise of the "valid" 3-tier argument. Confusion follows, since any kind of serious app will probably have douzens of layers, often distributed among 2 or 3 tiers (sometimes more for larger or distributed apps, but thats the average scenario at least).
Then comes something like MVC, which is 3 layer, and they associate all that together. 3 tier = 3 layer, MVC = 3 layer, therefore MVC can wrap my entire app. Which is obviously wrong. Just shows how a minor terminology mistake can mess up thousands of developers.
Thing is, thats already what they all do... they just get confused in the terminology. The amount of times I've seen people refering to MVC as a 3 tier... Thus, thats really the only thing that needs to be cleared up, and once you do clear it up, there isn't even any need to explain that you shouldn't put business logic in the controller anymore, it becomes obvious to most quite instantly.
Re: That should be obvious
by Chris Pellett,
Your message is awaiting moderation. Thank you for participating in the discussion.
I believe that one of the main reasons for the confusion is that people try and explain MVC in "tiers" or "levels" when this probably isn't the best representation. In the tiered approach, it is traditional for each layer to be able to talk to its neighbour (ie: 2-way communication). However, in MVC, this isn't quite the case. The controller can "talk" to the model, however, the model does not talk back. If anything, the most appropriate analogy would be a cycle - information flows in a circle between the elements (although, this still isn't quite correct)
Re: That should be obvious
by Francois Ward,
Your message is awaiting moderation. Thank you for participating in the discussion.
Tiers and layers aren't the same thing though :) And using a layered approach doesn't stop you from using MVC (since MVC is going to be one of your layers, almost certainly)
That is correct. MVC happens to have 3 main component, but that really has little to do with tiers or layers. MVC is an architectural pattern (so a building block for the whole), while a multi-layer architecture is just a basic architectural paradigm (where an MVC would be one of the layers), and a multi-tier architecture just describes physical (not logical) separation, such as in client/server ("true" multi-tier are less common in the web world, unless you consider the browser a tier... still not the same as when the whole n-tier stuff started being hyped).
It gets even more confusing to begginers when you add that the vast majority of MVC in the wild is tied to a framework, and in many cases, the framework does a lot more than MVC (such as Rails or ASP.NET MVC), so its hard for people to understand what part of it is the MVC.
Nothing a good class diagram (I'm not too fond of UML, but it would do the trick in this case) can't fix :)