The MVC Design Pattern On Web Applications

Originally written in May 2007 for a technology blog called (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:

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:

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:

Another intrinsical difference is their communication flow: 

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:

This was a great analogy, and we used that for a long time to grow our team.