Zend Framework / MVC: What type of objects to push to the View?

Question

Hey guys - here's a question on Zend Framework or better on MVC in general:

I am asking myself for a quiet a long time now, if it is a good idea to push business objects (User, Team, etc.) to my views or if it would be better just to push dump data containers such as arrays to the view for rendering.

When pushing business objects to my view I have a much tighter coupling between the views and my domain model, however, the view could easily do things like foreach($this->team->getUsers() as $user) { ... } which I personally find very handy.

Providing domain model data in dumb arrays to me looks more robust and flexbile but with the costs of that the view cannot operate on real objects and therefore cannot access related data using object's method.

How do you guys handle that?

Thanks much, Michael

Answer 1

I dont use Zend framework, so this is in repsonse to the general MVC Have a look at the ViewModel pattern.

http://www.lostechies.com/blogs/jimmy%5Fbogard/archive/2009/06/29/how-we-do-mvc-view-models.aspx

I'm comming from a .Net MVC point of view but I believe the concepts will the same.

Answer 2

I will do all my view rendering in the controller bascially like below

1. model only output dataset/objects (this should contain the most code)
2. controller assign view and add necessary HTML and make use of models
3. view only contains placeholder and other presentation stuff and maybe ajax call

So my team can work on each part without interrupting each other, this also add some information security to the project i.e no one can retrieve all the working code they only communicate by variables/object spec.

Answer 3

The "standard" approach would be to completely prepare the model in the controller (e.g. fetch all teams, including users) and then send that to the View for presentation, but you are not bound by that. The data structures can be whatever you want it to be: Array, ArrayObject or custom Classes - anything you deem appropriate.

See this similar question in Nabble

Answer 4

It's better to make your View access a Domain Model object in an object-oriented manner, instead of using the Controller to convert Model data into plain scalars and arrays.

This helps to keep the Controller from growing too fat. See the Anemic Domain Model anti-pattern. The Controller only needs to know what Model to instantiate, passes the request inputs to that Model, and then injects the Model into the View script and renders. Keep in mind that a Domain Model is not a data-access class.

You can also write View Helpers to encapsulate a generic rendering of a Domain Model object, so you can re-use it in multiple View scripts.

Your View should accesses the Domain Model only in a read-only manner. View scripts should not try to effect changes to the Domain Model.

You can also design your Domain Model to implement ArrayObject or other SPL type(s), as needed to make OO usage easy in the View script.

---

It's true, a large driving motivation of MVC and OO design in general is decoupling. We want to allow each layer to remain unchanged as the other layer(s) are modified. Only through their public APIs do the layers interact.

The ViewModel is one solution to abstract the Model so that the View doesn't need to change. The one I tend to use is Domain Model, which abstracts the details of table design, etc. and supplies an API that is more focused on the business rather than the data access. So if your underlying tables change, the View doesn't have to know about it.

I would expect that if there's a change to the Domain Model, for instance it needs to supply a new type of attribute, then it's likely that your View is changing anyway, to show that new attribute in the UI.

Which technique you choose to decouple one layer from the others depends on what types of changes you expect to be most frequent, and whether these changes will be truly independent changes, or if they will require changes to multiple layers anyway.