Understanding MVC Views in PHP

Question

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.

Answer 1

_{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.

Answer 2

The second tutorial is the way that Code Igniter framework works, and the one which I am used to. I follow it even when using no framework at all.

In fact, the developer must put the MVC-like principles in practice, otherwise he/she can make the lasagne or spaghetti even using the most MVC-like oriented framework.

Using the "PHP file as view template" approach, ideally one would use minimum PHP statements, basically only for repeat-structures (foreach ($array as $item)), basic conditionals (if ($boolean)) and echo - as if it was, indeed, a template language, and nothing more.

So, the <?php ?> tags in the view template files should be merely placeholders, and nothing else.

No database queries, access to the model, calculations, and the like should be performed in the view template file. It should be treated, basically, as an HTML file with placeholders. (With its associated CSS and JavaScript. Things may got more complex when the application relies on JavaScript / AJAX a lot...)

Following these simple principles, we effectively do some separation of the presentation from the business logic. Even sounding so simple, I'm tired of dealing with Code Igniter code which does not follow it. Some use "helper functions" to disguise the model/database calls - and think it is a good practice! :-)

You don't see a require inside these PHP view template files because they are required instead, from the "view building" methods.

Of course, one should not echo and/or print from inside the controller and model functions. This is also very simple, but I am also tired to see spaghetti code echoing out HTML from inside CI controller methods.

In practice, the controller calls the model methods, build all the necessary data for the view, and as a last step, calls the view (i.e., builds and output it), passing the already previously obtained data to it.

Makes sense? I don't know if I answered your question. At least, these are my "2 cents".