A Hitchhiker's Guide to MVC
Tags: beginners, systemdesign
Published: 2020-04-13 17:44:52

## Background.

MVC, or model-view-controller, is a prevalent software design pattern. It was pioneered by [Trygve Reenskaug](https://en.wikipedia.org/wiki/Trygve_Reenskaug), and [introduced in 1979](http://heim.ifi.uio.no/~trygver/2007/MVC_Originals.pdf) after a trip to the Xerox Palo Alto Research Center. (Never heard of the [Xerox PARC](https://www.mac-history.net/computer-history/2012-03-22/apple-and-xerox-parc)? You can learn more about its amazing story [here](https://www.youtube.com/watch?v=2u70CgBr-OI).) Why is MVC, a pattern which pre-dates the internet, still taught as an axiom of software design for web apps 40 years later? To answer that question, we first need to talk about *clean code.*

Any developer will tell you that in many cases getting the code to run is a lot easier than making the code clean. While everyone has their own taste as to what clean code is, generally clean code does a good job of being organized and easy-to-read. Like many system, code demonstrates entropy; the code will trend towards an inherent state of disorder. It takes *hard work* to keep code ordered and clean. MVC remains popular because it is indispensable in this effort. So what is it?

---

## Concept.

MVC stands for model-view-controller, and it is a framework for thinking about how human users can interact with programmed models (be they abstract or tangible). It's particularly useful in designing user-interfaces, including web apps. In a system designed around MVC, all responsibilities are split between the view, the controller, and the model. Let’s talk about the domain of a restaurant, and explore what these mean through analogy.

![MVC](https://upload.wikimedia.org/wikipedia/commons/a/a0/MVC-Process.svg "MVC")

######Fig. 1: A simplified view of the MVC framework.

---

## Example.

***View*** - Customers show up to a restaurant and sit down at a table, where they will *view* possible meal options on a menu and eventually their resulting meal. In most restaurants, to get a meal, you don’t cook it your self at the table. You give the waiter your order.

***Controller*** - Waiters act as the go-between for customers and chefs. They take meal orders from customers, give the orders to the chefs in a structured format, and eventually return the resulting meal to the specific customer that ordered it. Have you ever eaten at a restaurant where a waiter seemed to have perfect *control* of the situation? Where they seemed to know exactly where and when things needed to happen? The secret of any great waiter is their friendship with the chef.

***Model*** - A chef’s only job is to make meals. In the kitchen, they’ve got the two things they need to make a great meal: the cooking methods they’ve perfected, and the necessary ingredients on hand. A chef receives a customer’s order from a waiter, makes the customer’s meal, and gives the meal back to the waiter who puts it on the customer’s table. At a great restaurant, a chef is a *model* to the craft of cooking.

In terms of software, a view is responsible *only* for rendering information to the user. A controller is responsible *only* for directing various user requests to the model, and returning the model’s response. And a model is responsible *only* for the logic and handling of data.

A lot of popular web app frameworks, including **Rails** and **Express.js,** leverage MVC. Let's work with this example in Rails.

---

## Quick Code.

Rails is a *very* opinionated webapp framework that strongly encourages developing within the MVC framework. Here's a high-level view of how Rails web apps are structured:

![Rails Architecture](https://recipe4developer.files.wordpress.com/2011/09/image.png "Rails Architecture")

###### Fig 2. A Rails system diagram demonstrating an MVC pattern.

But, one of the advantages of being opinionated is that Rails is *fast*. One line in your terminal does a lot of the heavy, tedious lifting of building a webapp.

```bash
$ rails new restaurant
```
    

After you've started a new Rails app, you'll notice a directory in that project's root called app. Let's look what's inside there.



![Rails Directory](https://i.imgur.com/nJKBWjJ.png "Rails Directory")

###### Fig 3. The file structure of a new Rails app.

Wild! Rails insists that we build in MVC. And why not? MVC is a popular design pattern for a reason. Let's go over some of the benefits of sticking to MVC.

---

## Benefits.

1. **As a convention, MVC sets expectations for the underlying code and makes it easier to collaborate***.* If you asked me to help you debug a web app you had designed around MVC, right out of the gate we would have a shared understanding and language of the high-level patterns of your program. This saves a lot of time and headache in collaboration.
2. **MVC helps us separate concerns by assigning responsibilities across controllers, views, and models***.* Separation of Concerns is an essential design principle which developers use to build and maintain clean code. A modification to one part of our application will not effect the whole, and debugging will be more efficient. When we develop web apps around MVC, we stand on the shoulders of giants like Trygve Reenskaug who thought hard about separations of concerns about the past.
3. **MVC makes it much easier to parallel develop and ship clean code faster**. Because it separates concerns, MVC allows for effective parallel development. Different engineers can work on the model, view, and controller concurrently.

---

I hope this Hitchhiker’s Guide has helped you understand the MVC framework.