In this article, we’ll look at how MVC concept works in Ruby on Rails.
Image by CodingExercises
MVC stands for Model-View-Controller. Simply put, it’s one way to organize code, and that’s how code is organized in Ruby on Rails.
In OOP, Model is the data - or at least a way for our code to create, read, update, and delete records in our database. The View is the frontend of our app, and the Controller controls the routing of requests that happen due to the user interacting with the View.
For example, when a user clicks “Submit” on a form, the Controller is responsible of routing the request to another View, and possibly requesting the Model to perform some database operations.
In Rails:
- the Controller’s “formal name” is
ActionController - the Model’s “formal name” is
ActiveRecord, and - the View’s “formal name” is
ActionView
The ActionController and ActionView together are referred to as ActionPack.
When the MVC pattern is not used in Rails?
To be more efficient, Rails is set up so that all the requests made from the browser to the server initially check the public foder inside the Rails file structure.
If a file is found inside the public folder, then MVC is never reached, and the static html file is returned by the web server.
A simplified diagram would look like this:
HTTP request:
browser --> server --> /public
HTTP response:
browser <-- server <-- /public (file was found)
Thus, the MVC part of the framework is never reached.
If we look inside the public folder, we can see when such a scenario might occur.
Just looking at file names, we see that theres a 404.html file, a 422.html file, and 500.html file.
We can also just add static html files of our own. If we are certain that the file will not be changed very frequently, we might just add it inside the public folder. For example, the About page on most websites is usually not updated very often. Thus, it might be possible to just add about.html file inside the public folder, and have it served in no time, whenever a user requests this page on our web application.
Speed is the main reason to put files in the public folder in the first place. By circumventing the entire MVC processing, we can speed up significantly at least some parts of our web application.
What happens if a file is not found inside the public folder?
However, if the server does not find the file to return inside the public folder, the server will then look inside the MVC part of our Rails installation:
HTTP request:
browser --> server --> routing --> Rails MVC
Once our Rails installation processes the request using the MVC pattern, it will return the result of this processing in a response:
browser <-- server <-- Rails MVC
This means that sometimes, based on how the controller deals with requests, the processing will include the model querying the database and returning data from it; other times, the controller will just serve a static view.
Routing in Rails
All of the above steps wouldn’t be possible if it wasn’t for routing.
Routing receives the request from the server and “figures out” which controller and action to call.
Once this controller/action is called, then MVC in Rails is triggered, and it goes from there.
However, there’s a way to override this behavior. If we “mimic” the structure of a controller/action combination inside the public directory, then the controller/action will never be triggered by routing.
For example, let’s say we had an about controller and an index action inside of it.
Let’s also imagine we added another folder inside the public folder. Let’s call this sub-folder about. If we now add an index.html file inside the public/about folder, any request that looks like this:
https://<base-url>/about/index
… would never reach the routing in our Rails MVC; instead, it would just return a response from the public directory, because it would be able to find the “action” and “controller” combination: about/index.
