2

While using a custom MVC framework I found that the view can actually access data in the model. That was a bit of a surprise because I always thought the V must go through the C. It was something like

//this is completely made up but not far off
serverside foreach(var v in Model.GetSomeList()) {
    <div>@v.name</div>
}

Do many MVC frameworks in any programming language allow the view to access anything in the model? When do i choose what should go through the controller and what is ok to access from the view?

3 Answers3

0

This is common. If you look at the Wikipedia page for MVC, this is what it says for the view:

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

MVC is an architectural style, so some people change it as they see fit. From the design intentions of the architecture this particular question is certainly not frowned upon.

Marc Baumbach
  • 10,323
  • 2
  • 30
  • 45
  • -1 rails is not MVC or even remotely related to MVC design pattern. They are just using the names. – tereško Jan 20 '13 at 00:28
  • @tereško Do you mind expanding on that? Where are they not following an MVC architecture? – Marc Baumbach Jan 20 '13 at 00:37
  • The only thing missing in Rails is the notification of model changes to views. This was simply moved into controller logic due to the way the web works, since communication tends to be on a "pull" basis. While there's many variations on MVC around (both on and off the web), the answer holds true: Views often interact with models. – Marc Baumbach Jan 20 '13 at 01:02
  • Rails is also missing views, controllers and model layer. You can find explanation [here](http://stackoverflow.com/a/11984678/727208) (it would not fit in comment box). – tereško Jan 20 '13 at 01:08
  • I think you're overgeneralizing it, but regardless the Rails information is not relative to the question anyway, so I simplified the answer. – Marc Baumbach Jan 20 '13 at 01:22
0

Usually that "Model" is really like viewmodel, not the business layer Model object, although it could be the POCO version of the business object. Basically, the view is bound to some poco without any business logic.

AD.Net
  • 13,352
  • 2
  • 28
  • 47
  • So its ok the framework is doing this and it is common? I didnt realize the view can access anything from the model and it seems like you can bypass the controller easily. Also now it seems like its view<->model because why bother with a controller? –  Jan 20 '13 at 01:07
  • Actually, in my experience, what people call "model" is actually [active record](http://martinfowler.com/eaaCatalog/activeRecord.html) instance. Which essentially is an (anti)pattern made by merging [data mapper](http://martinfowler.com/eaaCatalog/dataMapper.html) and [domain object](http://c2.com/cgi/wiki?DomainObject)(domain entity, business object, model object). **P.S.**: I prefer the name "domain object" because it make it less confusing. People then to mix up terms "model layer" and "model object". – tereško Jan 20 '13 at 01:15
  • Sorry, my first comment was for the wrong post. But please see the comment below yours. That's what happens usually anyways. – AD.Net Jan 20 '13 at 02:04
0

Information flow in classical MVC.

Data in MVC should not go from model through controller to view. That is violation of the original concept.

If you read the original definition of MVC design pattern you will notice that Views are meant to request the data from Model. And views know when to do it, because they are observing Model for changes.

Modern interpretations.

In the original concept you were meant to have small MVC triad for each element in the application. In modern interpretation (as per Martin Fowler), the model is not anymore any single object or class. Model is a layer, which contains several groups of objects. Each with a different set of responsibilities.

Also, with the rise of Web there was another problem. You cannot use classical MVC for websites. Theoretically now you could achieve it by keeping an open socket and pushing a notification to the browser every time you changed something in the model layer.

But in practice even a site with 100 concurrent users will start having problems. And you would not use MVC for making just a blog. Using such an approach for even minor social network would be impossible.

And that was not the only divergence from the original concept.

MVC-inspired patterns

Currently, along with classical MVC (which is not even all so classical anymore). There are three major MVC inspired patterns:

  • Model2 MVC

    This is basically same classical MVC patter, but there is not observer relationship between model later and view(s). This pattern is meant to me more web-oriented. Each time you receive a user request, you know that something is gonna change in model layer. Therefore each user request cause view instance to request information from the model layer.

  • MVP

    This pattern, instead replaces controller with a presenter. The presenter request data from model layer and passes it to current view. You can find patterns definition here. It is actually a lot more complex, and I, honestly, do not fully understand it.

    In this case the View is passive and will not request any data from model layer.

  • MVVM

    This pattern is closer to MVP hen to classical MVC. In this case the controller-like structure (which actually would be more then a monolith class) request data from model layer and then alters it in such a way as it is expected by the (passive) view.

    This pattern is mostly aimed at situation where developer does not have full controller over views or/and model layer. For example, when you are developing some application where model layer is SAP. Or when you have to work with an existing frontend infrastructure.

    FYI: what is called "MVVM" in ASP.NET MVC is actually a good Model2 implementation .. what they call "viewmodels" are actually view instances and "views" are just templates that are used by views.

Community
  • 1
  • 1
tereško
  • 58,060
  • 25
  • 98
  • 150