MVC is a UI pattern…

Recently we had some discussions about how the MVC pattern of an ASP.NET MVC application fits into the application architecture.

Clarification: This post discusses the MVC pattern as utilized in ASP.NET MVC. Transferring these statements to other web frameworks (e.g. in the Java world) might work. But then it might not. However, transferring them to the client side architecture of JavaScript based applications (using knockout.js etc.), or even to rich client applications, is certainly ill-advised!

 

One trigger was Conrad’s post "MVC is dead, it’s time to MOVE on.", where her claims

"the problem with MVC as given is that you end up stuffing too much code into your controllers, because you don’t know where else to put it.”

http://cirw.in/blog/time-to-move-on.html (emphasis by me)

The other trigger was "Best Practices for ASP.NET MVC", actually from a Microsoft employee:

"Model Recommendations
The model is where the domain-specific objects are defined. These definitions should include business logic (how objects behave and relate), validation logic (what is a valid value for a given object), data logic (how data objects are persisted) and session logic (tracking user state for the application)."

"DO put all business logic in the model.
If you put all business logic in the model, you shield the view and controller from making business decisions concerning data."

http://blogs.msdn.com/b/aspnetue/archive/2010/09/17/second_2d00_post.aspx

Similar advice can be found abundantly.

 

I have a hard time accepting these statements and recommendations, because I think they are plainly wrong. (I mean no offense, really, it’s just an opinion.)

These statements seem to be driven by the idea, that the MVC pattern drives the whole application architecture. Which is not the case!
The MVC pattern – especially in web applications, certainly in ASP.NET MVC – is a UI pattern, i.e. it belongs to the presentation layer.

Note: I’m talking about the classical, boilerplate 3-layer-architecture for web applications…

In terms of a classical layer architecture:

This is how it works:

• The model encapsulates the data for the presentation layer. This may include validation information (e.g. attributes) and logic, as far as related to validation on the UI. Also I generally prefer value objects (as opposed to business objects, see also here).
• The controller receives the incoming request, delegates control to the respective business services, determines the next logical step, collects the necessary data (again from the business services), and hands it off to the view. In this process it also establishes the page flow.
  In other words: The controller orchestrates the control flow, but delegates the single steps.

 

Coming back to the original citations…

• If "you end up stuffing too much code into your controllers", then the problem is not MVC, not the fact that controllers by design (or inherent deficiencies of the pattern) accumulate too much code. It’s far more likely that the controller does things it’s not supposed to do. E.g. do business validations or talk directly to the database. (Or, frankly, “you don’t know where else to put it” is the operative phrase.)
• If your model "is where the domain-specific objects are defined", and you "put all business logic in the model", in order to "shield the view and controller from making business decisions concerning data", then these statements overlook the fact that domain-specific objects and business logic are artifacts of the business layer.

Fortunately you can find this advice elsewhere (I’m not alone after all!):

"In the MVC world the controller is simply a means of getting a model from the view to your business layer and vice-versa. The aim is to have as little code here as is possible."
http://stackoverflow.com/questions/2128116/asp-net-mvc-data-model-best-practices-for-a-newb

It’s just harder to come by.

That’s all for now folks,
AJ.NET

Advertisement