Why split the View in MVC into a view class and a

问题:

I'm relatively new to design patterns but I feel that I've got a good understanding of the MVC pattern and the advantages that this separation of code brings.

However, both times I've seen the MVC pattern in action (Magento and Joomla!), there is further specialization, with the view consisting of both a view class (Magento block) and a PHP template file. I would appreciate it if someone could explain the benefit of this split.

I'm also at a loss as to how to split my code between the view class and the template file. Sometimes I find myself writing what seems to be a redundant view class (in Joomla!) which simply accesses the model and then just makes the data available for the template. What code should appear in the template and what code should appear in the view class?

回答1:

View, in MVC-inspired design patterns, are responsible for all of you UI logic. They should be requesting information from model layer and, based on what they receive, choosing which templates should be used for creation of the response. Or even if any rendering is required (view can just as well just send a HTTP header).

_{You could say that in classical MVC and Model2 MVC patterns, the view only reads from model layer, but controller only writes to it.}

If you receive some error state from model layer, the view takes the main layout template and supplements it template, which is contains HTML fragment for error messages. Then it assembles the whole thing an shows to the user (which, in case of web applications is the browser).

Templates, in your basic web application, are just simple files with a mix of tags and php variables.

回答2:

You can consider the view as the what and the template as the how.

The view prepares the data by using the model and makes this data available to the template.

The template, in turn, is usually called (in Joomla!, at least) in the view's scope.

This may seem kind of redundant at first, but the power of this approach is revealed when using template overrides. Then, the view can be left alone, and only the template (or sub-templates, for this matter), be overridden.

Even using the same main (Joomla!) template, you may specify a different view template as a parameter, in case you need some specialization of presentation. This also eliminates code repetition.

For example, say you create a new main template. You can override some of the default views/templates and leave some others untouched. Then, you can create a new view, say, blog view, and also 2 templates for it, light spaced and dark dense, to be used in 2 different scenarios. This way, you only have one view to prepare all of the what and several different templates to take care of the how.

回答3:

In the general case, the split between a 'View' and a 'Template' is so that if you are going to present the view data via different methods [ie. HTML, XML, JSON, etc.] then you do not need to keep rewriting the 'View' class, only create new 'Template' classes. This is useful if you want to incorporate AJAX calls into your front-end, or make calls from other applications like a smartphone app for instance.

回答4:

Read this http://www.codinghorror.com/blog/2008/05/understanding-model-view-controller.html. To me MVC means registering a function to an array and loop through that array and eventually call a function in the main program. But for many people it seems to separate the model (database) from the view(html template) and the controller (the main application). But that's not what I would think is special about a program. When you develop web application naturally you have all this backends like database, browser, backend and frontend, html, css, image files, video files and php language etc. Why this is put into complicated words confusing the developement? I think MVC is to general to be useful. Learn the decorator pattern it's much more useful.

回答5:

To be honest...the best option for performance is to create web services in the backend and use a javascript library to talk to the server. joomla and other cms distributions try to abstract both of these design patterns into the MVC causing a hybrid of MVC and web services/ client-side code. such a hybrid nature allows for extensions to be extended into the javascript landscape which seems to be the direction the web is headed.