MVC: should view talk with model directly?

Question

earlier, many developer hold the opinion that view should not communicate with model directly, like most framework do.

and then, this opinion seems to be wrong, I find some articles, these articles say that view can communicate with model directly.

http://r.je/views-are-not-templates.html
http://www.tonymarston.net/php-mysql/model-view-controller.html
Model, View, Controller confusion
and
How should a model be structured in MVC?

most of these articles quotes a block from wikipedia, Model–view–controller, the quotes is:

A view queries the model in order to generate an appropriate user interface (for example the view lists the shopping cart's contents). The view gets its own data from the model. In some implementations, the controller may issue a general instruction to the view to render itself. In others, the view is automatically notified by the model of changes in state (Observer) that require a screen update.

ah, it's from wikipedia, such a authoritative site, it must be right!

but now, when I open the wiki link of MVC http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller, the page has be edited on September 14 this year(the year 2013), and the sentence above has gone.

the new definition for view is:

A view requests from the model through the controller the information that it needs to generate an output representation to the user.

now I'm confused again, the new definition says the view should request data from the model through the controller...

should the view access model directly on earth?

Answer 1

I think people have messed up concepts, terms and practices SO MUCH that it is hard to even communicate.

I know that MVC is a form of presentation layer architecture, and as such, its components should NOT contain business logic unless for some reason you want to duplicated some specific business rules in the UI. The problem arises, I think, when people stuff things like (most of the) business logic inside a view-model class in frameworks like ASP MVC (they claim that MVC does not prohibit this, but I am sure they ignore that correct layering does...).

Then their business layer gets merged with the view-model and thus with the presentation layer...

I think this should be avoided at all costs if you want to have some sort of layering in your project.

At least, that my take on this...

Answer 2

I think that most of the quotes around MVC are generally ok but I'll assume you are talking about...lets be specific and actually call it...Microsoft View Controller. As they tend to always add their own little bit (and while many disagree, in my opinion, I think for the most part their intentions are well formed but this is a debate for another topic).

I just wanted to emphasise that Microsoft-View-Controller is actually a different variant on the Model-View-Controller theme.

The way I use it is as follows:

I generally separate my concerns using various patterns because well lets be blunt...one of the slowest parts of any system is data access, followed closely by bandwidth. So I feel strongly that it is wrong to do as many suggest by putting business logic in the model for 2 reasons:

1. MVC (whatever variant) is a methodology to development that is designed to be extensible and maintainable.
2. There is no way in Microsoft-VC to connect a view to multiple models (unless you use ViewModels). This practice is encouraged and security concerns relating to connecting directly with the back end models abound. So needed or not, its generally considered bad practice to connect views directly to models and instead you should connect them with ViewModels.

MVC is a layered architecture. So layer it. By this I mean let EF do its job of mapping your tables to classes and leave it alone. Microsoft-VC forces people to apply a design pattern (Open/Close principle) to the model by auto-generating code using "Partial" classes. So you create your own empty partial class and then add your metadata to this. Its not a good idea to add code here as it becomes tightly coupled with the model. Instead...

Add a repository layer using the repository pattern. This uses all your model classes to do basic (very basic) CRUD. Then...

Add a domain (business) layer, and make it call the repo layer to get the data it needs to do the business rules...Then...

Connect your controllers to your business layers only and use a tool like automapper to map the data returned from the domain layer on to view models for your views.

As you grow in experience with this, you can later add interfaces between the layers as needed and its easy to apply the well known IOC pattern with some form of DI.

Hope this helps...But in general, the fact that MVC is a layered architecture means that adding layers is what it is designed to do so don't restrict yourself to only working with one way. Also remember, if you hear people saying that N-Tier multi layered architectures are for big systems only this is nonsense...every system is a big system. No business invests potentially at least 100's of thousands to develop a small system and leaves it at that (I know I get paid a lot of money to develop such systems, based on my salary alone and the taxes the employer has to pay above and beyond my salary, I can say with confidence that any company that employs more than 2 developers is already well past the 100K per year cost of developing so called "small" systems). All systems are designed to grow and the earlier you adopt this approach the easier your system will be to maintain and expand.

Answer 3

The following is a representation of dependencies in classical MVC architecture. You will notice that there is no arrow pointing from controller to view, because it is newer addition:

Source: GUI architectures

And then there is dependency map that is closer to what you will usually see in "MVC frameworks":

Source: Passive view

The "passive view" configuration is not part of MVC architecture. While it uses the same names, it actually is a variation on MVP pattern (you can find a longer and more detailed description in this publication)

Bottom line: yes, if you are implementing MVC or MVC-like architecture, then your views should be requesting information from the model layer.

Also, you should note that this is NOT what so-called "mvc frameworks" are pushing for. In the Rails-like frameworks there is no view. Instead (since the original structure was made for prototyping) the views are replaced with dumb templates and all the responsibilities of a view are pushed into something they call a "controller".

Basically, IMHO, the best way to name Rails-like patterns would be OLT: ORM-Logic-Template.

Answer 4

The "model" is your core application. Everything your application can do is in the model.
The "view" is there to visualize what's going on and provide a user interface.
The "controller" is the glue needed to react to events and instruct the model and view what to do.

Now, what options do you have for communication between the model and the view?

1. Push: all the data the view needs is being pushed into it, typically by the controller.
2. Pull: the view gets all the data it needs from where it needs it itself.

The second one is obviously more self-contained. If you need to push data into the view, that means someone outside the view needs to know what the view wants. And especially views can be quite dynamic and change often. Someone decides to display one more widget in the top right corner, and suddenly the view needs more data. That means other parts need to be recoded to push more data into the view. So you need to alter at least two independent parts just because the view was altered.

The better option is to give the view a handle that allows it to talk to the model and get all the data it needs itself. The controller just tells the view "we need form XYZ now, here's a handle to talk to the model, go!" and the view can do its job.