Once you pass a certain scale for a project, the architecture becomes critical. This happens way before its important for performance. It compartmentalizes behavior of your application into smaller pieces that can be worked on separately and efficiently. This is my first attempt at trying to describe where I think most implementations of MVC for the web fall short; I hope to provide a working alternative in the future. Until then I realize I'm just criticizing, but I still wanted to share my thoughts.
Model-View-Controller is a popular architectural pattern that's become fairly ubiquitous. For a standard, desktop application, it splits your code into three distinct sections.
Models are data structures that represent the data being worked with.
Views are definitions for the interface of your application and reflect the state of your models.
Controllers translate input in the views into actions on the models.
People don't seem to agree on how these communicate. Some people like views to display data directly from models, whereas others like the controller to sit in between all communication between models and views, whereas other implementations link views to directly pull content from the models themselves.
While there's some implementations that could be seen next steps to MVC (PAC, for example, or HMVC), there's also multi-tier. A typical multi-tier architecture might have
A data tier, representing the data itself, but unlike models, with no business logic,
A logic tier, where business logic is performed, and
A presentation tier, which handles both display and processing user input.
Both of these architectures, however, weren't designed with the web itself in mind, and translate somewhat awkwardly. In a typical, request based website,
User input is contained in the request but does not go through a view.
Initial requests contain all the input from the user.
All input processing must be completed before any interface is presented to the user.
All data must be retrieved from a persistence layer each time, so there's no transient states for models.
Views typically do not update to reflect the current state of models.
Typically, these differences lead to the follow simplification of MVC for the web:
Requests to directly to a special controller, a router, which chooses which other controller should handle the request.
The controller loads models from persistence and trigger business logic processing on them.
The controller loads a view, passing data from the models or the models themselves on to the view.
MVC works best views and controllers are as small as they can be. A single interface should be composed of multiple views and controllers. With a unique view and controller for each request, every request needs to implement all the decisions necessary to determine what models load and what business logic to trigger for every part of the current interface. In MVC, a controller should map specific user input to triggering specific business logic on models. Clicking on a button on might trigger the delete user controller, which would load up the related user model, and trigger delete on the model. The delete user controller should not be doing things like loading up recent posts for a section in the sidebar, or even be responsible for determining of the current user has permissions to delete someone else.
In practice, most websites implementations of MVC implement models correctly, but that's about it. Most routers route to a single method as the controller. Most views are full page templates. Instead of MVC, I'd rather call it MTP:
Models that represent the data,
Templates for the page to be rendered, and
Procedures that call business logic on models and pass the results to templates.
But wait, we have band-aids.
All things considered, MTP architecture has been implemented enough times that I'd say we've gotten good at it. For example, templates can include other templates (often called partials). Hooks can be defined so that multiple procedures can be called by the router instead of just one. Data can be passed between procedures and onto template through some kind of data object that can be manipulated by each procedure along the way. Some templates (sometimes called modules) can even contain their own simple procedures.
Templates and procedures, even with a router, are much worse than views and controllers. Briefly, before I go through an example,
Every procedure needs to be aware and check for all state data. Even with hooks and composition, either the procedure or the router does all the work of checking for permissions, or trying catching any errors separately.
Every procedure needs to be aware of all the data necessary for every template that will be used.
Sub-templates (partials) can only use subsets of the data the parent template has.
Let's talk through the differences between a MTP and MVC approach to handling an administrator deleting a user.
The differences start with routing. In our implementation of MTP,
The router routes a procedure.
A 'data object' is instantiated that is passed by reference to the procedure and all of the hooks. This is used to pass data between hooks, the procedure, and the template.
Hooks may be called by the router before the procedure.
Different hooks may be called.
In a final step or hook, the data object is matched with a template to render HTML.
The router routes to a 'top level' view.
The view loads any child views.
Each child view probably has a template, and returns rendered HTML (or equivalent) to its parent.
Lastly, the top level view is rendered to HTML.
Again, for our implementation of MTP,
Hooks and procedures both loads models.
Data from models (or even entire models) are put into the data object.
Order of execution is critical, as both hooks and procedures may depend on others to be run first to load certain models into the data object.
In the final step, the template references any data from models (or models themselves) to render HTML.
Views load the models they require.
Child views may be passed models from their parent, or ideally, child views would have read only access to their parents, however, in PHP this may just have to be a best practice.
The only order of execution that matters is enforced by having child views and parent views.
Each view is only responsible for returning back rendered HTML (or equivalent) its its parent, so in the final step, the top level is just composing views.
But what about controllers?
Backing up to how controllers are defined:
Controllers translate input in the views into actions on the models.
For the web, this is the most difficult part to translate. For most applications, input happens asynchronously, as events in particular views, and controllers are in a sense glorified event handlers. For the web, all input is given with the initial request. Secondly, on the web, input is only scoped to a top level view.
It would be easy to take top level views and add input handling into them... and that's where MTP comes from. But, when we mix the controllers into these views, we lose the separation of input handling from visual presentation. Or worse, we mix input handling into the models themselves.
Views should call controllers and pass input and related models to them. Let's talk through an example that shows the differences between all three:
Example: a company directory
Person – represents a person in the company directory. Has accessors (getName, getPhoneNumber) and mutators (setName, delete).
Department – represents a department of the company.
PersonController – handles editing a single user.
DepartmentController – handles editing a department.
LoginController – handles logging in a user.
desktop-view – top level view for desktops. depending on URL, may load
desktop-login-form – child view that shows up on the desktop site and is used to login. Passes input to LoginController.
view-user ‒ child view that loads a Person and display their information.
view-department – child view that loads a Department, every Person in the department, and displays the relevant information.
update-profile – allows a regular user to update their own details. Passes input to PersonController, and uses view-user to display the new version of the profile.
update-my-department – allows a uer to update their Department's details. Passes input to DepartmentController, and uses view-department to display the new version of the department.
mobile-view – top level view for mobile devices. depending on URL, may load
mobile-login-form – child view that is used by mobile devices to login. Passes input to LoginController.
mobile-view-user – different, mobile optimized alternative to view-user.
mobile-department – similiarly, a different mobile optimized alternative to view-department.
mobile-update-profile – allows a use to update their own details from their phone. Passes input to PersonController.
Desktop vs. mobile is certainly an easy way to see two different views that should share the same controller, but certainly doesn't need to be this strong of a separation. Any time you have multiple views (pages) that should share input handling benefit from this. Things like having a login form on multiple pages. If there's an admin and a regular user view that allow editing a profile, they should share a controller. Right now, we often link users off to a common page for editing a user to minimize this problem. Moving towards having separate controllers makes things like implementing editing in place or "double click to edit" without redirecting much easier to implement.
As I said initially, I hope to implement what I'm proposing so I can share that next, but I wanted to share my thought process so far. As I'm still in the design phase for this, I'm very interested in feedback.
izzy806
2087
ellievsbear
areudirty
prguitarman
snowghoul