Press "Enter" to skip to content

Ruby on Rails: An overview

Introduction

Ruby on Rails is a web development framework that allows for rapid development and deployment of web applications. It’s strongly opinionated and promotes intelligent defaults and conventions over custom configurations.

It follows the Model-View-Controller (MVC) architectural pattern which enforces separation between “domain logic” and the input and presentation logic associated with the graphical user interface (GUI) (Hartl).

As it’s name indicates, Ruby on Rails is implemented in Ruby, an object-oriented scripting language designed by Yukihiro Matsumoto with an emphasis on how the programmer “feels”. This philosophy was adopted and extended by the creator of Ruby on Rails, David Heinemier Hanson, as is evident by the Rails Doctrine.

Models, Views, and Controllers

To understand how Rails works, it’s useful to gain a general understanding of each component of the MVC pattern.

Model – The model is responsible for maintaining the state of the application and enforcing the business or domain logic that applies to that state. This includes how database records are retrieved, and how constraints are applied when records are created or updated.

View – Views are responsible for generating the user interface based on the data existing within the model. It formats the data and presents it to the user of the application. Multiple views can exist to present the same data. For instance, an “index” view may display a list of products, a “show” view may display a list a single product detail, and an “edit” view may allow a user to edit the data of a single product.

Controller – Controllers are the layer between the view and the model. They typically respond to user input (via a button or link click), and interact with the model, making it available to the appropriate view and displaying it. They are also used for permission checking, ensuring a user is authorized to access a specific resource.

Putting It All Together

In a typical Rails application, a user issues a request through a browser (or perhaps a mobile application that issues the request to a Rails API). The router examines the request URL and maps it to a controller action. That action may interact with the model, which in turn may interact with a database (or some remote API, or any other form of persistent storage). The controller action then invokes the view and renders it to the browser. To make this more concrete, consider the following example.

Say we have an application for managing an inventory of books, backed by  database with each book having it’s own unique ID.

IDTitleAuthor
1Eloquent JavaScriptMarijn Haverbeke
2Clean CodeRobert C. Martin
3Tao of Jeet Kune DoBruce Lee
4HTML & CSSJon Duckett

In this context, the following steps are taken as shown in the diagram diagram below:

  1. The browser issues a request with the url /books/1
  2. The router maps /books/1 to the “show” action on the books controller
  3. The books controller asks the Book model for an instance associated with an ID of 1
  4. The Book model queries the Books table for a record where ID = 1.
  5. The Book model returns the instance back to the controller.
  6. The Controller makes the instance of Book available to the “show” view, and returns it to the browser.
Rails MVC Diagram
Rails MVC Diagram

For further information, consider the resources listed below.

References

ruby-lang.org
The Rails Doctrine
The Philosophy of Ruby
Model View Controller
Hartl, Micheal. Ruby on Rails Tutorial
Ruby, Thomas, and Hansson. Agile Web Development with Rails 5
Bigg, Katz, Klabnik, and Skinner. Rails 4 in Action