Is MVC Sane to call a Model through Zend Framework's ViewHelper

Question

Recently I debated with a colleague of mine about to the following issue:

I claimed that it is not MVC sane and good practice to directly load a Model via Zend Framework's ViewHelper because it is a View related stuff and it should call another controller by a hard acceptance.

My colleague claims the opposite that a ViewHelper is being called prior to rendering the view that exists in a .phtml file, so it can call any Model and/or service required.

So I wanted to know who has claimed the most MVC-sane statement.

Please keep in mind that the problem that triggered this debate is on the web application we develop; we need to display reusable components of HTML which are being treated as widgets and to render them via Ajax will slow the entire site.

Answer 1

In the original MVC model, the controller interacts with the view and with the model. The view is notified by the model of change, and can access model content for the purpose of viewing:

To any given Model there is attached one or more Views, each View being capable of showing one or more pictorial representations of the Model on the screen and on hardcopy. A View is also able to perform such operations upon the Model that is reasonabely associated with that View.
- Trygve Reenskaug, the inventor of MVC

Loading data into the model is not a display operation. It's a a change of the model data in memory. This should be triggered by a controller and in no way by a view. By the way, most MVC variants, such as for example MVP, apply a similar logic (e.g. view only displays and never changes the model).

The Zend Framework however seems to have its own understanding of MVC, according to its manual:

View - Views define exactly what is presented to the user. Usually controllers pass data to each view to render in some format. Views will often collect data from the user, as well. This is where you're likely to find HTML markup in your MVC applications.

In a true MVC, the view never collects data.

Conclusion: you are fully right ! Nevertheless, in the Zend philosophy does not use a pure MVC, so your colleague may not to be fully wrong.

Answer 2

In your view scripts, often it is necessary to perform certain complex functions over and over: e.g., formatting a date, generating form elements, or displaying action links. You can use helper classes to perform these behaviors for you.

zend: view helpers

Among other things, this tells us that a view helper is not a view. It is a utility used by a view.

it is not MVC sane and good practice to directly load a Model via Zend Framework's ViewHelper because it is a View related stuff and it should call another controller by a hard acceptance.

The model contains data. Some of that data needs to be displayed in a view. So claiming this is only for "view related stuff" doesn't give you a nice clear cut off.

Best argument I know against this is that a view shouldn't poll the model. It's better if the view waits to be told that it's time to update and what to display. The view shouldn't know or care if it's the model that is telling it this. This wisdom doesn't come from MVC. It comes from tell, don't ask.

ViewHelper is being called prior to rendering the view that exists in a .phtml file, so it can call any Model and/or service required.

This makes the ViewHelper sound like a controller. If that's what it really is then fine. But that isn't what utilities used by the view should be doing. If that's what they are they should be concerned with providing the view the behaviors it needs to display the data it receives correctly. And that is what the zend documentation seems to say.

MVC is a very old design pattern. The only consistent thing about MVC implementations is the 3 areas of responsibility. Everything else: communication between areas, dependencies, flow of control, are all up in the air. Telling me you're using MVC doesn't really tell me that much. Sane or not.