LearnA Behind-the-Scenes Look at What Powers Ruby on Rails

What is Ruby on Rails?

Ruby on Rails is a web development framework that makes it easy to write web applications. Rails was extracted from an application called Basecamp. When you start writing a Ruby on Rails application, it’s like starting with 75% of a well coded application ready to go. Rails takes care of a lot of the boilerplate for you when working on a web application. You don’t have to worry about creating a router to different parts of your application, working with a good templating language, and writing all of the code to interface with a database.

What is a framework

A framework handles a lot of common use cases of an application for you. Let’s say we were starting to build a web application using Ruby and we weren’t going to use Rails or another framework. Here are some of the things we would have to build or assemble ourselves before we could even get started:

• CGI responses
• Database access
• Routing
• Templating
• Testing
• Email
• Logging
• Caching
• Internationalization
• Security
• Sessions and Cookie Storage

Ruby on Rails comes with all of these things built in. In doing so, it does take some choice away about what to use but it provides a ton of good, sensible defaults. You can always replace parts of of a Rails app if you need to.

One of the biggest benefits of using a framework is that, for the most part, there are standard places to put things (like configuration files, library files, etc.). This means that it is much easier for new developers to come on to a project than to a project — everything should, for the most part, be in it’s place. This is not a benefit that is exclusive to just Rails.

What is MVC

MVC stands for Model, View, Controller. MVC is a pattern for separating the different concerns of your application. It’s a relatively old pattern in computer sience — it was formulated in the late 1970’s. It was applied to web applications relatively recently and (arguably) popularized for web applications largely by the Rails framework. Here’s what Wikipedia says:

Model–View–Controller (MVC) is a design pattern for user-facing software that separates the representation of information from the user’s interaction with it. The model consists of application data and business rules, and the controller mediates input, converting it to commands for the model or view. A view can be any output representation of data, such as a chart or a diagram. Multiple views of the same data are possible, such as a pie chart for management and a tabular view for accountants. The central idea behind MVC is code reusability and separation of concerns.

Models

The models are the meat and potatoes of your application. The model will contain important business logic, and, in a Rails application, do most of the talking to your database. The model in an application is also responsible for enforcing certain limits or constraints of your application. For example, you may want to make sure that someone hasn’t signed up for your application using the same email address more than once, that their name contains a certain number of characters, etc. This is the model’s job. Rails comes with a number of ways to enforce these constraits, or validations, built in:

• Format
• Length
• Numericality
• Presence
• Uniqueness
• Confirmation
• Exclusion
• Several more

You can also write your own custom validations for the scenarios that Rails doesn’t cover. In addition, custom messages can be added. All of these validations can occur at different stages in the life cycle of a Rails model. This includes before and after creation, updating, and deletion where you may want to perform different functions such as sending emails, updating other records, or performing further business logic.

Views

The views in a Rails application will display information and render templates and layouts. As such, it’s a common practice to put as little business logic in a view as possible. That’s the job of the model (or a decorator or presenter). This isn’t always followed to a tee in an application but for the most part that is how apps should be approached. Different layouts can be applied to different sections of a site very easily.

Views in Ruby on Rails aren’t limited to just web pages. Using built in helpers, Rails can render json responses, xml responses, and even JavaScript templates. It is also possible to tell Rails how to handle other kinds of view templates, such as PDFs.

Controllers

The controllers will talk to your database and get the views the information they need. Building a to-do application? The controller will ask the model to get the appropriate to-dos for the project you’re working on. Are you trying to display all of the people in your address book whose names start with the letter ‘S’? The controller will ask the model to look those up. The controller will then make those things available in your view.

Controller in an Ruby on Rails application also serve specific functions like checking to see if you’re signed in to a protected area. In Ruby on Rails 4.0, controllers will also make sure that you’re sending in parameters that are allowed. For example, the controller would check that a user if your site didn’t put something like admin=1 in a registration form (or remove it if they did).

Convention Over Configuration

Though it is relatively common now, when Ruby on Rails was first released in 2005, many frameworks took an approach of heavy configuration to create an application. These configuration files could reach sizes of several hundred or several thousand lines of code. In a Rails application, everything has a certain spot. For example, Rails knows the following:

• Models belong in the app/models directory.
• Controllers belong in the app/controllers directory.
• Views belong in the app/views directory.
• Tests belong in the test (or spec or features) directory.
• Application dependencies are declared in the Gemfile.
• Configuration files are placed in the config directory.

That’s not the entire list — there are several more places that Rails makes assumptions about where things go in an application. As stated previously, this is a huge help to developers when approaching an application for the first time.

The Rails Ecosystem

One of the major benefits of modern Rails coding is the ecosystem that goes along with it. There are libraries that will do just about anything you can imagine in a web application. You can find them on sites like RubyGems.org, RubyForge and GitHub. There are several places to learn Ruby on Rails (ahem) and a multitude of companies that specialize in Ruby on Rails development.

So what are you waiting for? Dive in to learning Ruby on Rails. Of course, we’re biased, but Treehouse is a great place to start (and continue) learning. What do you think of Ruby on Rails? Let us know in the comments.