The MVC architecture and Rails Routes

Now we understand how the web works, we’ll study the MVC architecture and Rails Routes.

MVC stands for Model (M), View (V), and Controller ©.

On this architecture, we have the “separation of the concerns” among Models, Views and, Controllers. Each part has its own responsibility. Let’s dive in each part.

Model

“Maintains the relationship between Object and Database and handles validation, association, transactions”

It means that the model will maintain an extreme relation with the Database. Each model (can) represent a database table (in case of SQL databases). This model object gains capabilities (inherited from ActiveRecord — 

Besides that relation with the database, the model can create validations and associations between models.

View

“A presentation of data in a particular format, triggered by a controller’s decision to present the data.”

It is the presentation of the request’s response. This presentation can be a bunch of format types: PDF, HTML, JSON, etc. The final result of a view will be probably the user interface (UI) — Part of the “Client”.

For most pages on the web, the views will be an HTML styled with CSS and JS. But we can implement PDFs of user behavior on a Travel digital product to show all employees how people use their website too.

Controller

“The facility within the application that directs traffic, on the one hand querying the models for specific data, and on the other hand organizing that data (searching, sorting) into a form that fits the needs of a given view.”

The controller is the “Maestro”. It takes care of the flow: uses models to do queries, parses data, make decisions in which format you’ll present the data.

MVC & Routes cycle on a Rails application

Just think in the traveler perspective. You go to and you see a beautiful page listing a bunch of great articles.

The time you digit this URL in the browser, it makes a request to the server. In the server, we have the Rails web application. The Rails Router verifies if there is an entry matching the requested URL.

We just need to configure the routes for this line:

This will create RESTful routes for articles. If we run bundle exec rake routes, it will show the list of paths created.

The HTTP Verb can be GET, POST, PATCH, PUT, or DELETE. And we know how Rails maps each PATH to the right controller and action. Read more here.

In our case, the server will receive /articles path and GET as HTTP Verb. It will map to ArticlesController and index action.

In the controller ArticlesController we use the model Article to get all articles in the database and render the view index.html.erb as the server response (the UI).

By convention, this controller will render the view in views/articles/index.html.erb. Basically it’s a plain HTML file powered by Ruby.

The Rails request-response cycle is one of the first concepts you need to understand when you start learning web development.

The user does stuff (request to the server), the Rails application has the router to map the URL path to the right controller. In the controller, we can do all things with a model (or more than one model) — meaning getting, saving, editing, deleting data — and render a view to the user.