Note: This post is intended as a supplement to WTF Just Happened? A Quick Tour of Your First Rails App.

MVC and Rails

Understanding the MVC pattern is key to understanding Rails.

MVC divides divides the work of an application into three separate but cooperative subsystems: models, views and controllers. At a high level, models labour behind the scenes, views are the smiling face at the front, and controllers are the masterminds behind it all.

1. The browser sends a request to your Rails application.
2. This request gets picked up by the Rails Router (see Rails Routing for more details).
3. The router determines which controller action is responsible for responding to the request and it redirects it accordingly.
4. If data is required from the database, the controller will request it from the model.
5. The model will query the database to obtain the required data.
6. It then returns the data back to the controller.
7. The controller will then pass the data to the view and request the applicable template. The view takes the supplied data and uses it to generate a HTML document which it sends back to the controller.
8. The controller will then return the requested resource back to the browser.

Model

Models are classes that talk to your database. These classes inherit from ActiveRecord::Base which provides them with all the standard functionality detailed in the Active Record architectural pattern. They manage the relationship between your objects and the database. A model class encapsulates the business logic that is specific to your application through validation, association, transactions, and more. The model subsystem is implemented in ActiveRecord, which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records. Ruby method names are automatically generated from the field names of database tables. This is one of the examples of what people refer to as “Rails Magic”. You can read more about Models in MVC: Model.

Controller

Controllers take user input (like a URL) and decide what needs to be done. The Controller layer handles incoming HTTP requests and provides a suitable response. Usually this response is in the form of a HTML document, but it may also be XML, JSON, PDFs, and more. It directs traffic and queries the models for specific data, and then organises that data (searching, sorting, messaging it) into a form that fits the needs of a given view. This subsystem is implemented in ActionController, which is a data broker sitting between ActiveRecord (the database interface) and ActionView (the presentation engine). You can read more about Controllers in MVC: Controller.

View

Views display the output. The View layer is responsible for the presentation of data in a particular format. It is composed of “templates” that provide representations of your application’s resources. Usually these templates come in the form of a HTML document. This subsystem is implemented in ActionView, which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. You can read more about Views in MVC: View.

Other Resources

There is a great easy-to-understand explanation of how Rails implements MVC in the README of the Rails repository on GitHub. You can read it here. Scroll about halfway down the page to the heading ‘Welcome to Rails’.