Rails is an incredible framework that simplifies any developer’s day-to-day job. Despite its remarkable efficiencies, the learning curve to get to the point where things were “easier” was a tough one for me to round. One of the most important concepts was MVC, or model-view-controller. It is essential for any new developer to have a confident grasp on what MVC means and how it fits in to your Rails workflow. Each piece of MVC serves a unique purpose to power your web app. This separation of concerns provides explicit instructions for how the model, view and controller should interact with one another.
The model of your web app is responsible for most of its logic and saving/manipulating data. It is also where associations are set between your classes. There is zero user-facing content in the model. The model file should be a Ruby file. A example of a model called
drag_queen.rb can be found below.
class DragQueen < ApplicationRecord
has_many :venues, through: :gig
As you can see, the class is named
DragQueen and it will inherit from
ApplicationRecord. The next two lines create associations between the three classes. This is a small slice of the type of logic work that the model holds.
views folder for each model in your app. Within that folder, there are multiple views that correspond to controller actions. More on that later. For now, let’s take a look at the file
index.html.erb which lives in my
drag_queens folder, which is nested in my
<h1>Bring Back My Girlssss!</h1><p><% @dragqueens.each do |queen| %>
<%= queen.name %></p>
<% end %>
The above example is a very small snippet of code which is for a page that shows all of the drag queens in the database. As previously mentioned, there are multiple languages bouncing around at once in a view file. In this one, we see a classic HTML
<h1> header. Below that, there is some embedded Ruby (or ERB) for short. There are two types of tags in embedded Ruby– expression tags and execution tags. Within expression tags,
<%= %>, we are allowed to some Ruby logic, that then can be displayed along with the HTML. On the other hand, execution tags,
<% %>, are ways where we can hide some Ruby logic (like iteration) before an action occurs, but it isn’t displayed.
In the above example, we use execution tags (aka snow cones 🍧) to iterate over an instance variable,
@dragqueens, which happens to be an array. This logic isn’t visible, but plays an important role in the next step. We use expression tags (aka a squid tag 🦑and a snow cone) to then display each drag queen name. We close out the logic with an
end between two snow cones.
The above is a small example of what is usually in a view file. Each view has a corresponding controller action, which brings us to…
Controllers. Last but not least, the controller is the go-between for your models and views. There is a corresponding controller for each model in your app. Within each controller are tons of Ruby methods that are made available (or not) to their matching view.
class DragQueensController < ApplicationControllerdef index
@dragqueens = DragQueen.all
As you can see above, the class
DragQueensController inherits from
ApplicationController. There are generally tons of methods or functions in a controller, but the above action is just showing one. We are defining the method
index which takes all of the drag queens from the
DragQueen model and sets it equal to an instance variable,
@dragqueens. As we saw above, this instance variable was available to us in our view, which we iterated over to create a list of all of the drag queens. Controllers are critical in determining how a request should be handled.
To recap, MVC is an important concept to understand when building out web applications. The models, views and controllers of a Rails application/website are integral to receiving and processing user requests, as well as outputting the correct response. Practice MVC and remember what each part of MVC does to make your web app as efficient as possible.
NOTE: MVC is an extremely complicated concept, especially when you add in HTTP verbs, routing and RESTful conventions to the mix. This is meant to serve as a brief overview to remind you of “what goes where” when building out a Ruby app.