Why is it called MVC?

Ruby on Rails is an MVC framework.

You’ve heard that phrase many times over.

You even know what the individual words mean – Model, View, Controller.

And you’ve got a pretty good idea of how it works.

But the web request goes in to the Controller first. The Controller does stuff with the Model and somehow the View renders something (but we’re not exactly sure how it knows what to render). Isn’t it really Controller-Model-View? CMV?

To find out why it’s MVC, we need to go back into the mists of time. When men were real men, women were real women and tyrannosaurs hadn’t become chickens.

Do you know what to do but not how it works?

Ever wanted to understand why Rails views work the way that they do? Why variables from your controllers are visible inside your views?

Sign up below to get a free 5 part email course on how Ruby on Rails view rendering works and gain a deep understanding of the Rails magic.

We will send you the course, plus the occasional update from this web-site. But no spam, we promise, and it's easy to unsubscribe

In these olden days, there was a system called Smalltalk. I may have mentioned it before – to my mind it’s the single greatest achievement in computing there has ever been. The Smalltalk machine (designed by Xerox) either invented or was the first practical use of loads of technologies that we now take for granted. The Graphical User Interface, the Integrated Development Environment, the mouse, networking, virtual machines, image files and Object-Orientated Programming.

The Smalltalk language was designed to be readable by seven year olds and was based around two core concepts – everything is an object and everything you can do to an object is done via message passing. You can see this today in Ruby, which is a direct descendant of Smalltalk, as is Objective-C (although both have loosened those concepts in the name of practicality).

In Smalltalk, they used Object-Orientated programming because it was intended to model the real world. They used a Graphical User Interface to show those things on-screen.

So the “things” in a Smalltalk system were known as Models.

The representations of those things on-screen were known as Views.

You would instantiate a Model (in a Transcript window, which is basically an IRB shell within the Integrated Development Environment), then create a View and tie the two together via what Smalltalk called “the Dependency Mechanism”. This means that whenever the Model changes it tells the world it has changed. The View hooks into that and updates itself accordingly.

What is really important here is that the View knows about the Model, but the Model has no knowledge of the View. (This idea of who knows what about whom is essential to understanding Object-Orientated programming).

The View then shows stuff on-screen. But when the user uses the keyboard, or the new-fangled mouse, to interact with the View, the View doesn’t know what to do with that. Instead, a Controller intercepts the keystrokes or mouse clicks or other inputs and then figures out what they mean, and sends messages to the Model, telling it that the user has done something. The Model updates itself, the View receives a notification from the Model and then it redraws the screen.

So the actual communication channels look like this (which is where the MVC comes from):

Model sends notifications to the View.
Controller sends messages to the Model.

And the actual “knowledge graph” looks like this:

Model knows nothing apart from about itself and any related Models.
View knows about the Model.
Controller knows about the Model.

Compare that with a Rails application.

A web request is received and dispatched to a Controller (via the Router). The Controller finds the relevant Models, maybe sends it a few messages (invokes methods on it) and then renders a View with those Models.

The communication channels look like this:

Controller finds and sends messages to the Model.
Controller renders and passes data to the View.

And the “knowledge graphs” looks like this:

Model knows nothing apart from about itself and any related Model.
Controller knows about the Model and the View.
View knows about the Model and the Controller.

These differences are arguably because an interactive, desktop-style, environment has a very different life-cycle to a stateless response-request web environment.

Objective-C is a direct descendant of Smalltalk and macOS and iOS’s libraries all follow a similar MVC pattern as well. Likewise, some client-side Javascript frameworks, such as KnockoutJS and Angular follow the same path.

But Rails is MVC as well; just a different (and less clean and manageable MVC) designed for a different environment with a different lifecycle.

PS: If you want to know how Rails ties a Controller and View together, so you can actually understand what’s going on there, instead of leaving it to Magic, then sign up below.

Do you know what to do but not how it works?

Ever wanted to understand why Rails views work the way that they do? Why variables from your controllers are visible inside your views?

Sign up below to get a free 5 part email course on how Ruby on Rails view rendering works and gain a deep understanding of the Rails magic.

We will send you the course, plus the occasional update from this web-site. But no spam, we promise, and it's easy to unsubscribe