Model View Controller (MVC)

The fundamentals and the Rails way ❤️

In this article, we’ll go over the fundamentals of MVC and how they apply to Rails.

Before we get into the rails approach to MVC, let’s first define MVC.

MVC

Previously called “Thing Model View Editor”

MVC is a design pattern for software application architecture. It divides an application into the following parts:

1. Models for handling data and business logic.
2. Controllers The director of interaction between the model and the view.
3. Views for handling graphical user interface objects and presentation.

This separation results in user requests being processed as follows:

1. The client sends a request for a page to the controller on the server.
2. The controller retrieves the data it needs from the model in order to respond to the request.
3. The controller gives the retrieved data to the view.
4. The view is rendered and sent back to the client for the browser to display.

Model

It is known as the lowest level because it is in charge of data maintenance. Handle data logically so that it primarily deals with data. The model is actually linked to the database, so anything you do with data.

The model component is where data is added or retrieved. It responds to controller requests because the controller never talks to the database on its own. The model communicates with the database and then provides the required data to the controller.

It’s worth noting that the model never directly communicated with the view.

View

The view component is in charge of data representation. It creates a user interface (UI) for the user. So, when you think of the view component in web applications, just think of the HTML/CSS part. Views are generated by data collected by the model component, but these data are obtained indirectly through the controller, so the view only communicates with the controller.

Controller

The controller is known as the main man because it is the component that allows the interconnection between the views and the model, acting as an intermediary. The controller does not have to deal with data logic; it simply tells the model what to do. After receiving data from the model, it processes it before sending it to the view and explaining how to represent it to the user. Views and models cannot converse directly.

The MVC Cycle

Although MVC comes in a variety of flavors, control flow is generally implemented as follows:

MVC Cycle — Rails Novice to professional

1. The user interacts with the interface and triggers a request to the server (e.g., submits a registration form).
2. The server routes the request to a controller, passing any data that was sent by the user’s request.
3. The controller may access one or more models, perhaps manipulating and saving the data in some way (e.g., by creating a new user with the form data).
4. The controller invokes a view template that creates a response to the user’s request, which is then sent to back to the user (e.g., a welcome screen).
5. The interface waits for further interaction from the user, and the cycle repeats.

MVC the Rails way

Model

The model layer in Rails represents the database. Although the entire layer is referred to as the model, Rails applications are typically composed of several individual models, each of which (usually) maps to a database table. By convention, a model called Book would map to a table called books. The Book model is in charge of all database access to the books table, including creating, reading, updating, and deleting rows. So, if you want to work with the table and, say, search for a book by author, you use the model, as shown below: Books.find_by author: 'Ali' Although simple, this snippet searches the books table for the first row with the author column value Ali and returns the results.

Rails’ built-in database abstraction layer, Active Record, is used to accomplish this.

Controller

Controllers are the MVC application’s conductors. Controllers in Rails accept requests from the outside world, process them, and then pass control to the view layer to display the results. It is the controller’s responsibility to handle web requests, such as processing server variables and forming data, inquiring about the model, and sending information back to the model to be saved in the database. Although this is an oversimplification, controllers generally respond to a user request to create, read, update, or delete a model object. In the context of Rails, these terms are frequently abbreviated as CRUD. In response to a request, the controller typically performs a CRUD operation on the model, creates variables for use in the view, and then renders or redirects to another action once processing is complete.

Controllers are typically responsible for a single area of an application. In a book application, for example, you will most likely have a controller dedicated to book management. You can define what are known as actions within the books controller. Actions define what a controller is capable of. You create appropriately named actions in the books controller if you want to be able to create, read, update, and delete books. A basic books controller would look like this:

View

The view layer in MVC is the application’s visible component. Views in Rails are templates that (most of the time) contain HTML markup that will be rendered in a browser. It’s important to remember that views are supposed to be free of all but the most basic programming logic. To keep the view clean and decoupled from the application’s business logic, any direct interaction with the model layer should be delegated to the controller layer.

The Libraries That Make Up Rails

Rails is a collection of libraries, each of which performs a specific function. When these individual libraries are combined, they form the Rails framework. Three of the libraries that make up Rails map directly to the MVC pattern:

• Active Record: A library for dealing (handling) with database abstraction and interaction.
• Action View: A templating system that generates the HTML documents that a visitor receives as a result of a Rails application request.
• Action Controller: A library for manipulating both application flow and data from a database as it is displayed in a view.

Fat Model, Skinny Controller

The phrase “Fat Model, Skinny Controller” refers to how the M and C components of MVC should ideally work together. Specifically, any non-response-related logic should be included in the model, preferably in the form of a nice, testable method. Meanwhile, the “skinny” controller serves as a convenient interface between the view and the model.

Summary

Now that you’ve mastered the fundamentals, you can explore the wonderful world of clean architecture with Rails, specifically how to separate concerns with use-cases, entities, and adapters.