Model, View, Controller
What is MVC? I briefly touched on it in my previous post from Week 6 but we should dive deeper, so let’s do just that. MVC stands for Model, View & Controller. This is the foundation, on top of which, Rails built upon. Think of MVC as the architecture of the Rails framework, that is basically what it is. In order to better understand this, we will break down each component one by one. As we progress, check back with the diagram below for a visual representation of how each component of the MVC works together.
The Model of the MVC works directly with our database. The database that we use in Rails is ActiveRecord, which stores all of the data that we need for our application. Inside of our database, we can have many tables which represent many things and those tables can be linked together through something called associations.
The name of each table in our database is plural (e.g.
students), this is because each table represents a collection of one thing – many students, many teacher, many cars etc. Each table has both columns and rows. The columns of the table represent different attributes of the elements in that table (e.g.
gender etc). Each row of the table represents a new instance of that database object. So in this sense, our columns would represent attributes of a student while our rows would represent individual students.
Rails uses the
Model as a way of interfacing with the database, indirectly. The model creates a ruby
class representation of our database object. With this newly created
model we are able to do many things based on user interaction.
The controller is our point-man, it is the mediator between all of our moving pieces in Rails. The controller actually relies on one other piece of Rails that is left out of the MVC definition and that is our
If you navigate to your
config folder, you will find a file named
routes.rb. This file is responsible for monitoring the actions of the user and then initiating the proper controller to handle the request of the user. This is done through what is often referred to as
rails magic. This is achieved based on naming conventions.
To better describe this, let’s imagine we have a simple web app that tracks
reviews for those restaurants. When a user goes to
routes.rb file will look for a controller corresponding to that naming convention. Our controllers, models, database tables, routes and views will all be named similarly – the only difference being location of the files and naming in either the singular or plural, rails does the rest!
Pro-tip: The following are always in the plural: routes, tables, views folder and controller whereas model files are always in the singular because they represent a specific instance of a database object (a row in our table)
Once it finds the proper controller,
restaurants_controller.rb it will then call on the
index method inside of our controller. The
index method will be responsible for listing all of our
restaurant objects. Inside of our
index method, it would look something like –
@restaurants = Restaurant.all.
Our routes file knows to utilize the
index method of our controller because navigating to
/restaurants is a
GET request, much like what we learned during Week 1 of Sinatra. If we had, on this page, a form for submitting a new
restaurant our controller would utilize the
create methods once the submit button was clicked by the user.
This brings us to our views folder. Our views folder will have folders inside of it corresponding to the controllers available. In this case, we would have a
restaurants folder and inside of that folder, we would have
views files that correspond to the methods we defined inside of our
Included methods would be
edit. Each one of these methods corresponds to
CRUD – Create, Read, Update & Destroy. It is worth noting that we would be explicitly defining access of these methods (for the user), from our
We do this by declaring resources like so:
resources :students. Doing this would give access to all
CRUD actions but we could limit the user to only a few by doing the following:
resources :students, only [:index, :show]. This would only allow the user to see all students listed together and an individual show page for each student.
We then need a way of displaying the information that is containing inside of our methods. To do this, we create corresponding views files for each method. The syntax to do this is as follows,
method_name.viewing_format.erb. What does this mean?
method_name part says, if you want to display the
index method, create an
index view page. The
viewing_format is a way of telling the browser the type of file to convert all of our code to, in this case we want
html because we plan on displaying it to the user. This if followed by
erb because we want to be able to use a little bit of logic when necessary, like creating conditional
div tags that only display given certain circumstances.
The final result would look like this:
Bringing It All Together
The user directs to a page, the
URL of which tells the
routes.rb file to go looking for a controller that matches that specific
If the controller is found for that
URL and the
HTTP request of the user has a valid method inside of that controller (e.g.
show), the controller will run that method.
Each method draws on information stored in our
ActiveRecord database but is only able to do so indirectly. In order to store, retrieve, update or destroy data in our database, the controller uses the
The model file provides our controller with a
ruby representation of our database, allowing the ability to interface with the database. It is the mediator in this scenario. Remember that
model filenames are singular because they represent individual instances of database objects.
Once the controller has successfully interfaced with our database via the
model, it will then output to a corresponding
view file in our
All of this is able to happen based on
rails magic , which is only possible through the proper use of syntax and naming conventions. Rails
routes automatically goes searching in the controller folder based on user input and expects to find a controller that corresponds to the
URL the user is on because that is the convention of the Rails framework – deviating from this will require overriding the built in configurations, so don’t do that, just learn to play by the rules and you’ll be happy as a result!
As you can see, the Rails framework is a highly powerful tool that affords us the ability to create web apps and quickly deploy them. Adhering to the Rails conventions is the quickest way to getting your app into the latter stages of development. Make sure to pay attention to how files, folders and classes are named get in the habit of sketching out your ER diagrams before beginning a project in order to get a better understanding of how every piece will work together throughout the entire app.