I have to seem problems grasping the concept of Views in MVC, they are, according to what I've read, the layer that manages the presentation in the aplication, but many of the material I've been reading seem to be different regarding this matter in this one from PHP Master.com.
The View is a class with functions that return some HTML code, where is the rest of my HTML? should it be put in independent .html pages that access this View code?
In this article, from php-html.net the View is a simple HTML file with a .php extension, but how are they accessing that data? I see no
require() or anything like the instantiations in the first tutorial.
Let's start from the beginning ...
The core idea behind MVC and MVC-inspired design patterns is Separation of Concerns. Said separation is two-fold:
Model layer (not "class" or "object") would contain several groups of structures, each dealing with as different aspect of business logic. The major parts would be:
Also there might be mixed in repositories, units of work and others.
UI layer mostly consists of views and controllers. But they both utilize services to interact with the model layer. Services provide the way for controllers to change the state of model layer and for the views to gather information based on that new state.
In context of web the views and controllers form a loose pair, because of the request-response nature that web applications exhibit.
It should be noted that although controllers can alter the state of the current view directly, it's more common that these changes are effected through the model. One reason to alter the view directly is, for example, when instead of XML you need to respond with JSON.
Though it also could be argued that one could simple instantiate a different view for each output format and take advantage of polymorphism.
What is not view?
There is a widespread misconception that views are simply glorified template file. This mistake became extremely popular after release of RubyOnRails prototyping framework.
Views are not templates. If you use them as such, you break the core principle behind MVC and MVC-inspired patterns.
If you pretend that templates are views, it has an enormous impact on your architecture. There is no place for presentation logic in the view, therefore you push the presentation logic either in controller or model layer. The usual choice is "controller", because most of people understand that presentation logic has no place in model layer.
Essentially, this causes a merger of views and controllers.
What is view doing?
The responsibility of the view is to deal with presentation logic. In context of web the goal for view is to produce a response to the user (which, btw, is the browser not the human).
To create this response view acquires information from model layer and, based on gathered data, either assembles response by distributing data to templates and rendering or sometimes simple sending a HTTP location header.
Highly subjective bit:
Lately I have preferred to interact with MVC using following approach:
$methodis the current REQUEST_METHOD, that has been adjusted fake a REST-like API, and the
$commandis what people usually call "action". The controller has separate routines for
POST(an other) requests. This helps to avoid having same
ifin every "action".
And on the view I call similarly named method, that prepares a response that is sent to the client.
What about DRY?
As you might have noticed already, there is a slight problem with having views as instances. You would end up with repeating pieces of code. For example: menu or pagination.
Lets look at pagination .. The pagination contains logic, but this logic is not related to the model layer. The model has no concept of "page". Instead this bit of logic would reside in the UI layer. But if each of your views contains or inherits pagination, then it would be a clear violation of SRP (and actually several other principles too).
To avoid this issue you can (and should, IMHO) introduce presentation objects in your views.
The presentation objects deal with repeated pieces of logic. This makes the views much "lighter", and in some aspects starts to mirror the structure of services from the model layer.
The interaction between presentation objects and templates becomes similar to the interaction between domain objects and data mappers.
Do I always need all of this?
No. This specific approach is heavily geared towards code, where the UI layer has a lot of complexity and you need to separate the handling of input from presentation just to sane sane.
If your application has very simple UI, like .. emm .. you are making REST API for a larger integrated project. In such the pragmatic option can be to just merge every controller-view pair into single class.
It also can be a good step, when refactoring a legacy codebase, because this less-constrained approach lets you move entire chunks of old code. When you have isolated such pieces of older code and checked, that everything still works (since legacy code never has any tests .. that's how it becomes "legacy"), you then can start splitting it up further, while focusing on separating business logic from UI.