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.
Advertisement
Answer
Note: the MVC and MVC-inspired patterns are advanced constructs. They are meant to be used in codebases where ordinary object-oriented (that follows SOLID and other guidelines) code starts to become unmanageable. By introducing this pattern you would impose additional constraints, which then lets you to contain very complex applications. MVC is not meant for “hello world” apps.
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 is separate from UI layer:
- views are separated from controllers
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:
- domain objects: validation, business rules
- storage abstraction: persistence and caching of data from domain objects
- services: application logic
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).
Technically it would be possible to create client side views, that user web sockets to observe model layer, but in practice it’s virtually impossible to implement. Especially not in PHP environment.
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.
When using Post/Redirect/Get, the redirect part is performed by the view, not the controller as often people tend to do.
Highly subjective bit:
Lately I have preferred to interact with MVC using following approach:
// the factory for services was injected in constructors
$controller->{ $method.$command }($request);
$response = $view->{ $command }();
$response->send();
The $method is the current REQUEST_METHOD, that has been adjusted fake a REST-like API, and the $command is what people usually call “action”. The controller has separate routines for GET and POST (an other) requests. This helps to avoid having same if in every “action”.
And on the view I call similarly named method, that prepares a response that is sent to the client.
Warning:I suspect that this setup contains an SRP violation. Adopting it as your own might be a bad idea.
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.
Note: while Fowler calls them “presentation models”, I think that name just adds to the whole ‘what is model’ confusion. Therefore I would recommend to call them “presentation objects” instead.
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.
P.S. I myself am still struggling with figuring out a way how best to deal with views. This post is less of an answer and more like a snapshot of my current understanding.