The MVC Design Pattern On Web Applications

Originally written in May 2007 for a technology blog called CFGigolo.com (which used to be a Google Page Rank 7), this article described my vision for improved web application in both terms of interface and reach. At that time I was on a great team developing corporate web application. A lot happened since: more capable smartphone, evolution of web programming languages, the boom of mobile and so on. I’m glad the world evolved more than my vision were able to capture at that moment. I hope we continue to execute and evolve more than our mind limits.

Design Pattern

There’s a lot of talking on “MVC” on software development. People starting developing web applications or “Rich Internet Application” talk about that too. Several web development frameworks allow or require it, therefore there’s even more discussion about it.

The way to understand the MVC architecture (I find more descriptive calling it an architecture instead of a framework or paradigm) is the same to understand any design pattern:

• which problem it solves (the motivation behind this pattern)

• understand the pattern

• understand how this specific pattern solves our recurrent problem

Increased Complexity, Need to Decouple

When the software starts to get too big and complex, and a lot of data is presented to a user, we need to separate the data (model) from the user interface (view), in a way that changes in the user interface doesn’t interfere on how they manage the data.

To accomplish that, we decouple – remove direct relationship – between the user interface and data access. We do that by using an intermediary element, called controller, that will manage this relationship.

Therefore, the responsibility for each element has a defined scope:

• The Model represents information from the application domain (payroll, for instance) e supply function to operate these data (e.g. calculate the payroll amount). Consequently, the model exposes application functionality. It also notifies the View when data is changed.

• The View should render the Model and allow user interaction. It also should query the Model when it notifies about data change, therefore keeping consistency between them both.

• The Controller, the orchestra conductor, answers to user action (a click on a button for example), allow changes in the Model by requesting new data from the server for example and select the View to be displayed.

Hence, by decoupling the View from the Model and with specific accountability, complexity is considerably reduced, also allowing developer specialization, something with increasing importance due to the increasing importance of user interface.

This flow can be synthesized by the chart below, inspired by a – let’s say – vintage Sun Microsystem chart:

MVC and Three-Tier Architecture: Scope and Flow

It’s critical not to mix MVC with Three Tier Architecture; the latter is an architecture for client-server applications and those tiers represent distinct systems: the presentation, business, and data layer could be for instance an HTML interface, a Java code on the server and a SQL database on the server. Fundamentally the presentation layer can never access the data directly, thus using the intermediary layer (or layers).

Although MVC and Three Tier seems the same thing, the level and scope are fundamentally different:

• The MVC design pattern refers to the code of an application (i.e. the software) itself, what the user sees, and interact with.

• Three Tier Architecture refers to a topologically higher level, between different systems.

Another intrinsical difference is their communication flow: 

• On the MVC it’s a triangle course of communication. The View sends commands to the Controller, which updates the Model, and the View access the new data on the Model.

• On the Three-Tier Architecture, the flow is linear. From the presentation layer to business, from business to data, and backward.

Let’s not mix those two concepts up!

The Three Monkeys and the MVC

When Beck Novaes and I were working together to put together a whole big team (50, maybe even 70 developers) to develop a web application with Adobe Flex and Cairngorm, we created a bunch of ideas and concepts to simplify their migration to web development. One of these concepts was related to MVC.

The Three Wise Monkeys represent a proverb from the Asian culture and most of the time associated with Buddhism. It has one monkey covering his eyes (see no evil), one covering his ears (who hears no evil) and the last one covering his mouth (who speaks no evil).

We associated them with the MVC, which made total sense and a didactical way to memorize and explain the rationale behind it: