Tag Archive: ruby on rails

Ruby on Rails Design Patterns

July 10th, 2013 Alina Guzman Web Development 4 Comments

My class started working with Rails this week, which was groundbreaking. After so much time spent on writing out simple CRUD apps on Sinatra (a light-weight web framework), it is a relief to be introduced to the MVC pattern! Ruby on Rails is a web framework that was written to emphasize several out-of-control-awesome design patterns, including active record, convention over configuration, and model-view-controller (a.k.a MVC).

MVC is a design pattern that separates and organizes all the code you write for an application – data, logic, functions, routes, and what the user sees as the output on the screen. It was hard for me to really understand the value of this pattern since I never learned how things are done otherwise. Our work with Sinatra does shed some light, however, and it becomes more clear to me why our course is structured the way it is. Jumping straight into Rails would have left a lot of blanks to fill. Sinatra doesn’t follow the typical MVC pattern – it jumbles up all of the elements that MVC so nicely separates.

Why does it matter anyway?

Well, I think one of the main advantages to this kind of architectural pattern is the re-usability it provides. The model represents a databases table as a class that takes properties from Active Record making it so you don’t need to write SQL. It still runs the SQL behind the scenes, but it lets you interact with the data in familiar Ruby terms.

The views consists of what the browser will display, made up of mostly HTML and a little erb code. And the controller houses the logic that communicates with the model and sends the views to be displayed. This system allows you write a lot less code in a lot less places. With Sinatra, I had to retype a lot of database requests. While ActiveRecord solved the majority of my database-request problems, MVC furthermore reduced the number of places I had to write them. Repeating yourself is not very DRY (don’t repeat yourself). Kind of goes against the whole point of programming, doesn’t it?

Perhaps my favorite and sometimes most exasperating pattern in Rails is convention over configuration. The whole theory behind this starts with the very brutal fact that when faced with a new Rails application, there is a ton of configuration to complete to even render a blank page to the browser. With every app, you will need to link data to logic.

Say you have a bunch of tables in your database, like Users, Addresses, Courses, Images, etc. All of these tables will have to correspond with a class that tells it how to behave (for example “I want to take the names of Users and display them here”, or “Put this users images on this page”). That is a lot of code you have to write to map each table to its respective class blueprint.

What’s the solution?

Naming conventions. Rails knows that if you have a table named Users, you will have a class named User. Similarly with Images and Image, Addresses and Address, and etc. Adhering to naming convention allows you to avoid writing many configuration files (you can always overwrite or add to any configuration if you need, however). While this is awesome, it’s also a double edged sword. If you miss an ‘s’ or name something wrong somewhere (naming convention goes beyond just tables and classes), everything goes ‘ka-boom‘. I have only been coding for a few weeks, but most of that time is spent staring at errors trying to decode them. My longest error starring contests came from these naming convention errors.

Tags: , , ,

Find me on…

What I’m Tweetin’