These days, most, if not all, of the top application and web frameworks use the Model-View-Controller design pattern, hereinafter fondly referred to simply as MVC. Wikipedia defines MVC as:

Model–view–controller (MVC) is a software architectural pattern for implementing user interfaces. It divides a given software application into three interconnected parts [the model, the view, and the controller], so as to separate internal representations of information from the ways that information is presented to or accepted from the user.

If you do some searching for MVC on the web, you’ll run across all sorts of explanations of what it is, how it works, why it’s going to save the world, etc. Now, maybe my Google skills really suck and I just haven’t found the perfect MVC article that’s lurking out there somewhere on the internet, but most of the explanations I’ve run across are either too simplistic to give my understanding any depth or too technical to be helpful.

Thankfully, I ran across the awesome book Head First Design Patterns, which takes a bottom-up (specifics -> big picture) approach to understanding MVC. The book does this, and quite masterfully I might add, by demonstrating that the MVC design pattern is simply comprised of several other design patterns, namely the Composite, Observer, and Strategy design patterns.

Now, an in-depth discussion of each of the above patterns is outside the scope of this post; however, here’s how I like to envision each of them in layman’s terms:

Composite: When you want to work with something that’s made up of many smaller, diverse, potentially complex parts, it’s nice to work with the bigger thing and then let it manage its smaller parts. Take your car for example – do you really want to have to interact with the spark plugs when you want to accelerate? Or is it simply more convenient (and safer!) to interact with the gas pedal and let your car handle the details?

Welcome to the Composite design pattern! It allows you to work with many smaller things but just think of them as one big thing.

Observer: If you want to be notified when new posts are made on a blog, you can either:

  1. Keep checking it every so often to see if any new posts have been made since your last visit, or

  2. Use email or RSS to subscribe to the blog and be notified of any new posts.

The second approach describes the Observer design pattern. It saves you (the observer) time and saves the blog (the observable) resources (bandwidth from unnecessary visits, etc.).

Strategy: Let’s say your internet service provider (ISP) has recently upgraded its internal customer service systems from using antiquated software solution A to using modern software solution B. That’s awesome! However, as a customer, you don’t really care how your ISP handles service requests. All you care about is what happens after you call, email, chat, etc. to inform them of a problem you’re experiencing with your internet.

The Strategy design pattern is basically a fancy name for the same idea. It allows how a service is performed to vary independently of the client using that service.

With the above in mind, check out the following diagram of the MVC design pattern I created using the info from the Head First book (along with some of my own amazing artistic skills):

Understanding MVC

Isn’t MVC easier to understand when you think of it as simply made up of other design patterns? Here’s a brief rundown of how each design pattern contributes to the overall MVC design pattern:

Composite: The View is comprised of many smaller user interface objects, but the user gets to treat them like one big object. This allows the rest of the application to treat the user interface as a single entity too while letting the View worry about what’s going on with its individual parts.

Observer: Rather than constantly checking for updated data or for the results of requests its made, the Controller can sit back and relax. It’s subscribed to the Model, so, anytime the Model has updated info for the Controller to handle, the Model will automatically let the Controller know without the Controller even having to ask.

Strategy: Since the Controller is really the brains of the program, wouldn’t it be nice if we could easily swap out the brain to change the way our program works? Furthermore, wouldn’t it be nice for the View to simply ask the Controller to handle user interface events without having to worry about how the events will actually be handled? Thanks to the Strategy, this dream is a reality in the MVC design pattern.

And that’s pretty much it! MVC gives applications the power to run smartphone apps and huge websites like Twitter while also giving them the flexibility to adapt, swap pieces in and out, and grow over time.

Let me know what you think of my attempt to make MVC more accessible for us “normal human beings.” I’ll consider this page a work in progress that will (hopefully!) become better and more helpful over time