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?

sorry, but I find many resemble topics on this site and find no answer, so I just post it here... — cifer, Sep 18 '13 at 13:07
@tereško you say the wiki article's change is vandalism just now, why edited your answer? Have you found the appropriate reason why the article be changed? — cifer, Sep 18 '13 at 13:24
Because there is a lot of bad information out there. All the Rails-like frameworks are using term "MVC" as tool for advertising. You think someone will be all hyped up if they started to advertise that they are using extremely dumbed down version of [PAC](https://en.wikipedia.org/wiki/Presentation-abstraction-control)? — tereško, Sep 18 '13 at 13:27

score 25 · Accepted Answer · edited Feb 08 '17 at 14:09

25

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:

enter image description here
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.

edited Feb 08 '17 at 14:09

Community

1
1

answered Sep 18 '13 at 13:24

tereško

58,060
25
98
150

I wonder why the wikipedia change the definition of view... to bring a new definition of MVC? – cifer Sep 18 '13 at 13:28
2

Wikipedia is not some monolithic source of knowledge. All the changes are no by people. And some people are stupid. – tereško Sep 18 '13 at 18:54
Fowler refers to the MVC, as a GUI architecture. If this is correct, then say that the M of MVC are the business rules, data, logic, etc., is not wrong? – Maykonn Nov 08 '13 at 20:40
@Maykonn could you rephrase? I have no idea what you are trying to ask. – tereško Nov 08 '13 at 20:44
If MVC is a GUI architecture, is correct to apply this architecture in an application domain? Look: http://martinfowler.com/eaaDev/uiArchs.html – Maykonn Nov 08 '13 at 20:50
1

what is "domain application"? – tereško Nov 08 '13 at 20:53
@tereško you are amazing because you have nailed it.Great job indeed. – kta Nov 13 '16 at 01:44
@dakis this answer is outdated – tereško Aug 15 '18 at 17:44
Can you please elaborate relations in classic mvc? As I understand from schema, Controller make inputs to Model (->), but what is the relation between Controller and View? View would interact with Controller via Model? – Botea Florin Jul 30 '20 at 05:41
@tereško now that it is outdated, what is the current "state of the art" in this stuff? MVC seems like an awfully mystifying topic but perhaps because so much here is obscured by jargon terms that have not been adequately defined (and esp. maybe also because I'm coming at this from a desktop / games / mobile app development pov and not a Web [PHP etc.] pov, but like the pattern because of the SOC aspects.). – The_Sympathizer Sep 09 '20 at 20:00
Also, is it a deviation from strict MVC pattern if View or Controller objects register themselves with model layer objects so as to be informed of _events_ from it? (as in another post you said about that model services should not have views register with them, but what about with event updates, which suggests some form of listener/observer pattern in there?) – The_Sympathizer Sep 09 '20 at 20:03

score 17 · Answer 2 · answered Sep 18 '13 at 13:10

17

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?

Push: all the data the view needs is being pushed into it, typically by the controller.
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.

answered Sep 18 '13 at 13:10

deceze

510,633
85
743
889

thanks for answer! I learnt some new points from you. I wonder why the wikipedia change the definition of view... – cifer Sep 18 '13 at 13:29
2

@deceze Your statement _The controller just tells the view "we need form XYZ now, here's a handle to talk to the model, go!"_. I never thought of the controller passing in a handle to the model to the view. You have deepened my understanding of MVC! Thanks! – thegreendroid Jun 12 '15 at 03:03
1

In regard of the view, can you please give an example of a _"handle that allows it to talk to the model"_? Also, shouldn't the view be able to request and display the data from the domain model by itself? E.g. shouldn't the view own an own handle? Why would the controller pass something to the view, like a handle? Thanks. _P.S: Is your answer still up-to-date? If not, I'd be very interested in your current perspective._ – PajuranCodes May 29 '20 at 18:39
@dakis One word: dependency injection. That’s mostly what I mean by “handle”. Of course it’s not strictly necessary, but IMO a good idea. – deceze May 29 '20 at 19:24
Sorry, I'll insist a bit: 1) So by _" to give the view a handle"_ you mean something like, for example, injecting a service to the view, through which the view fetches the model data that it needs to display? Or do I misunderstand something? 2) How and why is the controller involved in this? 3) If you don't mind, a little piece of code would be really great. – PajuranCodes May 29 '20 at 20:05

Francis Rodgers · Answer 3 · 2014-10-10T09:35:13.980

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:

MVC (whatever variant) is a methodology to development that is designed to be extensible and maintainable.
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.

score 1 · Answer 4 · answered Nov 10 '14 at 16:28

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...

MVC: should view talk with model directly?

4 Answers4