MVC: pass model / model data to a view from a controller?

Question

If a view needs to acces data from a model, do you think the controller should:

a) pass the model to the view
b) pass the data of the model to the view
c) neither; it shouldn't be the controllers concern. Let the view access the model directly to retrieve the data. Only let the controller give some parameters the view needs to filter the data from the model.
d) it depends on the situation.
e) none of the above, but [...]

Thanks

After some debate in the comments to an answer that was deleted by the user, maybe this needs clarification. My view of the MCV architecture is biased towards that of the Zend Framework (php) in which an action in a controller by default has a default view assigned to it. So it's not so much the model that dictates which view is approporiate, but rather the controller. Do you feel the model should dictate what view is appropriate? The only way I see fit to let the view be build based on a model, is by letting the controller pass the model to the view. Are there other techniques to let a view access a model without the controller being involved? Or is it perfectly fine to let a controller pass the model to a view, so that the view can be build based on the models attributes?

Answer 1

uhh b.

i dont really see the difference between a and b other then some technicallity of how you will be passing data.

usually you pass a map of data to the view with some data from the model

Answer 2

Ideally, it should "pass the data of the model to the view" so the view doesn't need to know any explicit structure of the model and thus be more reusable and designer-friendly.

But practically, "pass the model to the view" works as just fine. Most of the time you will need a new view anyway because clients never share favorite colors (if you know what I mean :-) so views re-usability doesn't justify having a lot of tedious code required to copy data from the model to the view.

What you should concern more about is the modularity of the controller itself, since many websites do share common functionalities (controllers) such as web forums or a news listing but not looks (views)

Answer 3

a) pass the model to the view

Otherwise the controller is manipulating the view via screening the model. This is what would happen in "b) pass the data of the model to the view". The b) option doesn't really even make sense in the pure MVC pattern. After all, the model IS the data. If the model is changed for consumption, a view has been applied, whether you choose to do it in the controller and pass it off as a controller function. What happens when you have a different view? Does the controller screen its data differently? You soon have two views for model, the controller sub-view and the view itself.

Answer 4

e) None of the above; pass in a view-optimised "ViewModel".

Example in ASP.NET MVC:-

public ActionResult Details(int id)
{
  Product p = ProductService.GetProductById(id);

  if(p == null) { return RedirectToAction("Index"); }

  ProductViewModel model = new ProductViewModel(p);
  return View(model);
}

both a) and b) "will do" subject to d). Never ever c).

Typically, the ViewModel just encapsulates the Model (if nothing complicated is going on, your view could access the model directly via ProductViewModel.Product). If the view needs to do anything complicated with the Model however, it's the ViewModel's responsibility to do that, rather than the responsibility of the Controller, or the View.

This keeps your concerns nice and segregated. Your Controller doesn't care exactly what specific data your View needs (beyond the fact that it's rendering some Details of a Product), or especially what format your View needs that data in. Your View doesn't depend on the implementation details of your Model. Your Model doesn't have to concern itself with how it's being Viewed. If you have two Views rendering Products (e.g. Create, Edit, Summary, MoreDetails etc), those Views can have different ViewModels to expose only the data that each specific View needs, so your Views aren't depending on eachother. Lovely :)

Some further reading from various viewpoints:-

http://www.thoughtclusters.com/2007/12/datamodel-and-viewmodel/

http://stephenwalther.com/blog/archive/2009/04/13/asp.net-mvc-tip-50-ndash-create-view-models.aspx

http://www.nikhilk.net/Silverlight-ViewModel-MVC.aspx

I think ViewModels are a particularly .NET thing, but I see no reason at all why the pattern can't be used in PHP.

Hope this helps.

Answer 5

For me that's e).

As already mentioned here, ideally the view and the model are decoupled. The way I prefer to implement this is to have a viewHelper for a model. This has the API the view can use to get the data. Now views are not affected by changes in the model and the view doesn't need to 'get' the internals of the model. These are hidden away by the viewHelper.

example:

class Post {
    public function export(ViewHelper $helper) {} // I try to avoid getters when I can
}

class PostViewHelper {
    public function getTitle($parameters) {} // title of current post in the loop
}

class PostView {
    private $helpers = array();
    public function loadTemplate($path) {}
    public function addHelper(ViewHelper $helper, $name) {}
    public function __get($key) {} // if exists $this->helper[$key] etc
}

in a template

<h1><?php $this->post->getTitle(); ?></h1>

You may want to implement this differently. But my point is in how the view and the model are decoupled, introducing an intermediate viewHelper wich creates the view/template API.

Answer 6

I don't think it's that complicated. a or b.

The controller's job is to manage the relationship. It finds the model and view and provides the view all the model data it needs to do its job. That's it. MVC doesn't dictate the exact form the data takes.

(a) Start simple. It's pretty natural to pass the model objects directly to the view. If you have a page about a Foo, just pass the Foo.

(b) But at times-- and only at times-- you create a value object / DTO to get the data to the view (called a ViewModel above). Do this when there's a mismatch between the view and the native model, such as summary views. If the view is presenting a summary of 1,000,000 objects, you don't want to hand the view the model objects; you want to hand the view a summary of the 1,000,000 objects.

And the exact implementation really depends on the language and framework you are using. But I think these guidelines are a good start.

Answer 7

Hi,

This is late I know, but I'm having this issue on a project I am working on. I started with a) - for simplicity - and now running into road blocks.

I am coming around to this method:

e) None of the above; pass in a view-optimised "ViewModel".

because it avoid bloating both your model classes (instances of which are "transaction objects") and your views. For example, you may need to render a number with a specific number of decimal places (this is the problem I am having now).

With an intermediate "ViewModel" this is easy - you just write the relevant ViewModel "getXXX" method to return the number formatted how you wish.

If you just pass the model directly into the view, you will need to specify it in the view every time you use this figure (going against DRY - don't repeat yourself), or alternately, add a rendering method to your model classes (which goes against a class being for one purpose only).

Cheers