Why MVC Matters

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.

Model

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. grades, ages, 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.

Controller

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 routes.

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 restaurants and reviews for those restaurants. When a user goes to /restaurants, the 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 new and create methods once the submit button was clicked by the user.

View

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 restaurants_controller.rb file.

Included methods would be index, show, new, destroy, create, update and 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 routes.rb file.

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?

The 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: index.html.erb or show.html.erb.

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 URL path.

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. index, 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 model file.

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 views folder.

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.

Resources:

One comment

Submit a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s