1

I read somewhere that one should not pass plain model objects to view, but only read-only objects. So, currently I have something like this in my controller: 

$user = new User(); // Model class
$user->loadUserById($id);
$this->setData('user', $user); //obviously $this refers to the controller object
$this->displayView();

And then, I render the fields I want in my template. Is there something wrong to this approach or it is totally acceptable to pass model objects to view?

iiirxs
  • 4,493
  • 2
  • 20
  • 35
  • 1
    One for http://programmers.stackexchange.com/ – Progrock Aug 19 '16 at 15:09
  • 2
    In principle the view shouldn't modify anything it receives. However the practical answer really depends on what kind of project you're making. If you're alone you can probably get away with passing the models and forcing yourself not to modify them. – apokryfos Aug 19 '16 at 15:11
  • _The model cannot save itself?_ So the view can do whatever it wants? Or, The view doesn't see the model but an array or stdClass object of the data? – Ryan Vincent Aug 29 '16 at 18:28
  • @RyanVincent that was the question if I should pass an array or stdClass object instead of a model object. The model can save itself, so in a way if someone would like to do such things he could possibly do that. But why would he? – iiirxs Aug 29 '16 at 18:41
  • Wasn't criticising: Perhaps not everyone who will maintain the system is future is as knowledgeable as yourself? I have no idea what others will do with data. However, if they can modify it and it not affect anything then that is what I would do. imo, models should not be able to save themselves. imo, All models should have a means of exporting the useful information to an array. Makes it easy to pass data about the system? But requires access to the 'business model (domain)' to change anything. Safe? Just my opinions - free and worth exactly what they cost :) – Ryan Vincent Aug 29 '16 at 18:53
  • I agree about the model not to be able to save itself, it should be by a data access layer. But if you have a model without the ability to change something in the database, why to casting it to an array or stdClass object? It is would be enough safe to handle the model object itself, since it cannot mess with the database or something like that. – iiirxs Aug 29 '16 at 18:54
  • 1
    The export to an array, imo, is useful 'cos other data sources can provide data in array format (forms, JSON, csv etc.) And a view that expects an array rather than an a specific object is more flexible at displaying the same model information from different sources. – Ryan Vincent Aug 29 '16 at 18:59

2 Answers2

1

This is kinda complicated.

The recommendation to provide "read only objects" (they probably use a word "immutable") is a slightly exaggerated conclusion from a larger principle regarding MVC:

Views should not alter the state of model layer.

Changing the state of the model layer is the responsibility of controllers. That said, controllers are not responsible for passing information to the views in MVC. That's what ViewModels are for in MVVM and Presenters - in MVP.

I would also note that you should not confuse "views" and "templates". A view utilizes templates, but it's responsibility of to produce response that reflect the sate of model layer. You might find this interesting to read.

Community
  • 1
  • 1
tereško
  • 58,060
  • 25
  • 98
  • 150
  • If controllers are not responsible for passing information to the views, then who is? – iiirxs Aug 29 '16 at 18:57
  • 1
    Nothing is. The view (in MVC, as opposed to MVVM and MVP) is expected the inquire about the state from the model layer (usually thought services). In classical MVC that inquiry is triggered by view [observing](https://en.wikipedia.org/wiki/Observer_pattern) a change in the model layer. In web MVC (due to it's request-response nature) you already know which parts of model layer will be altered in each request and know which specific services to request data from. – tereško Aug 29 '16 at 19:04
0

I guess the reason to avoid passing a model object is, someone who is working on the view may be tempted to do some "business logic" in the view. That would break "separation of concerns".

You don't have to worry about it if:

  • You work alone.
  • You work in a smallish team of disciplined developers with plenty of communication.
  • You use a template language like smarty to render views. In accepted practice, such a language lacks the power to do business logic.
Juan Tomas
  • 4,905
  • 3
  • 14
  • 19