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.
|2||Clean Code||Robert C. Martin|
|3||Tao of Jeet Kune Do||Bruce Lee|
|4||HTML & CSS||Jon Duckett|
In this context, the following steps are taken as shown in the diagram diagram below:
- The browser issues a request with the url /books/1
- The router maps /books/1 to the “show” action on the books controller
- The books controller asks the Book model for an instance associated with an ID of 1
- The Book model queries the Books table for a record where ID = 1.
- The Book model returns the instance back to the controller.
- The Controller makes the instance of Book available to the “show” view, and returns it to the browser.
For further information, consider the resources listed below.
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