[pattern.mvc] The Model View Controller (MVC)

Many readers will already know about the MVC pattern, but since MVC is so often implemented poorly (especially for the web) it gets a mention here.

Like its name, the Model View Controller consists of three parts:

Model

The Model contains all of the reusable business logic an application needs, including:

• data.  This can be direct access to databases or indirect access to data through queues or web services.

• business rules and calculations.

• integration with third parties.

• batch processing that isn't related to the user interface.

The philosophy of the Model is that if the owner of the software wanted to add a completely different kind of user interface to the solution, everything in the model would still be relevant.

For example, a web application should be able to be rewritten as a Swing application without changing the Model at all.  For large projects that are developed well, the model is the only truly reusable piece of code.  For this reason models are often developed as web services.

Trap: The application Model is not to be confused with the User Interface Model, which is part of the View and stores information to help drive the user interface.  The UI model for a website might keep user preferences, role authentication, form classes and session information which would be thrown away if the web interface was decommissioned and replaced by a different style of application (e.g. on an Android phone).  Consider keeping two sets of database tables, one for the Model, and another for the UI Model.  

View

This is a layer that displays information to the user, and gathers information from the user about what they want to do.

Tip: In pure MVC theory the View and Controller layers have separation of concerns.  This means that either the View or Controller can be completely replaced with something else and everything runs fine, but in practice this isn't so.  The Controller and View are usually so closely tied to each other that if one changes, the other also needs to change.  Spring MVC Controllers generally have Spring MVC aware JSP files.  The view layer tends to blend in with the controller because in typical modern Controller classes, half of the code deals with processing user input and the rest deals with preparing data for a View.

Controller

This module knows what to do with user selections and holds the rules about which screen is displayed next.  Controllers knows which services to call to:

• validate data

• save data

• get enough information to render the next screen.  

Complex navigation rules are also encoded in controllers.

Don't be too concerned if some things in the Controller don't have an obvious location, like cookies.  Cookies are used in the view, but data information in them is usually managed by a Controller.  As long as they are not part of the Model, the location is probably OK.

Trap: Reusable controllers.

The most important MVC layer to build as a reusable module is the Model because it is probably the only piece that might ever be revived for another project. I have never yet seen a case where the View was thrown away yet the Controllers were kept.  So don't get too caught up in trying to split the View and Controller layers cleanly from each other.

Since controllers and views and URLs are closely tied to each other it is easy for maintainability to get out of hand if conventions are not agreed early.  Take Spring MVC for example, which uses annotations to describe page URLs and views.  If a Spring MVC page fails to load it can be difficult to know where an annotation has been missed, because the screen simply fails to render.  This situation can be improved if you choose one set of naming conventions and code style and stick to it.

Samples of filenames from a Spring MVC project that was allowed to evolve without a plan:

A little research shows that these were all related to the same activity, searching for invoices or searching for payments.  Given a URL, a developer would have difficulty knowing exactly which files might be responsible for a bug, or what annotations might have been missed.