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.