Understanding Rails Terminology, Principles, Components and Architecture

by Saurabh Bhatia

October 29, 2009

Rails Architecture - The MVC Pattern

The Rails framework is based on the Model-View-Controller (MVC-II) design pattern. This means, the code in the application is abstracted within the application in such a way that the Business Logic, Application Flow Logic, and the user interface logic are separated from each other.

The Model handles all the data related operations inside an application. It contains database relations, data abstraction, validations and the entire business logic of applications. It interacts with the view to get the data and pass it to the database.

The View handles the User Interface Logic. Rails Views are much more interactive in nature, rather than being dumb HTML. They also use the Object Oriented nature of Ruby ,by writing the Ruby code inside special markup tags and embedded Ruby templates with an extension .html.erb.

The Controller handles the Application logic, which is the flow of the application. It defines how an application should respond to users actions in the front end. It takes the request from a view in the browser, sends it via web server to the appropriate Model to fetch, insert and delete data that follows up with the action that is supposed to come after the data operation has been carried out.

Inside our Rails application directory, these parts reside in the app folder. Checkout figure 1 to see the directory listing inside the application folder.

Click here for larger image
Figure 1

Rails Jargon

DRY: Do not Repeat Yourself abbreviated as DRY is a concept generally followed as a good design practice in programming and is one of the most important practices while programming Rails. Rails implements all the Object Oriented pattern of development and hence DRY becomes extremely important because that's what Object Orientation is all about, reducing the redundancy and increasing the reusability. Rails is structured in such a way that DRY and reusability is forced into the framework as much as possible and it makes it a habit for the developer to follow these standards. In this regard, Rails code is also considered much more modular and cleaner than code written in many other languages and frameworks.

Convention Over Configuration: One of the terms that Rails promoters always use is Productivity. Productivity of Rails is largely because of one of the core principles of the framework, known as convention over configuration. Rails, rather than providing extensive configuration files like XML definitions (struts, spring, hibernate mappings in a typical Java web application), provides a standardized set of keywords and conventions that a framework uses to make the different parts of an application talk to each other. The schema tables being defined as a plurals (yes Rails does understand English, so its an intelligent framework too), singular names of the models, relationship definition and indexing inside schema using keywords like has_many (a keyword to say category has many products) , validation framework which sounds much like English (validates_uniqueness_of check if the value in a textbox is unique or not before inserting in the database).

This is a huge advantage in many terms, the most important being avoiding loss of time because of monumental application efforts. This reduces redundancy and encourages reusability. Finally, it makes it easier for people to learn because of clean syntax, a definitive set of rules to follow (while building an application, not before it) and hence provides a head start in terms of development, as well as a steep learning curve.

Scaffold: Scaffold is one of the reasons why Rails became immensely popular in it's early days and why it was also mistaken as a framework for prototyping rather than something that powers some of the most popular sites around the world (twitter.com). It's a feature that helps to build a functional web application just at the stroke of a command. The concept of scaffold has changed radically across the various versions of Rails. Until Rails 2.0 was released, scaffold command, used to go to the database, read the tables, datatypes and generated a skeleton code for performing basic CRUD operations inside the database. In order to break this shell, the scaffolding was changed quite a bit in the versions post Rails 2.0. Now, the generated views are empty.

ActiveRecord: ActiveRecord is the Object Relationship mapping tool that ships with the Rails framework. It is the perfect example of implementation of the above mentioned rules of DRY and convention over configuration. It maps objects to the database and provides the necessary interface of the Rails application to the database. The internal SQL queries, the inter-table relationships, the table indices are defined inside ActiveRecord.

Rake: Is a tool written in Ruby used for carrying out build operations. It is quite relevant to rails as we can build databases, load test data, run tests and build default documentation using rake.

Getting Into the Rails Directory Structure

When we create a Rails application, the following directories are created by default. We will briefly see the significance of each one:

1. App: As mentioned earlier the app directory contains, models, views and controller code. Apart from these three pieces of the application, it also contains something called helpers. Helpers are Ruby classes that can be reused inside a model, controller or a view with a similar name.
2. Config: Although Rails does choose convention over configuration, there is some minimalistic configuration that needs to be done in order to run the application. All these files are in a format called YAML (YAML Aint a Markup Language) which calls itself a human readable data format language. The config folder contains, database.yml for defining the database driver, and credentials, environment.rb for defining the Rails environment setup and routes.rb to define application specific flow, environments folder to define configurations related to Development, test or production environments.
3. Db: As the name suggests contains the schema definitions and table definitions in the form of migrations. Migrations make it immensely easy to build SQL tables and increases the portability of the Rails application. All the tables are defined in terms of a specific Ruby syntax and then the tables are created accordingly.
4. Doc: This contains the standard definition of the application classes and uses rdoc, a Ruby generated documentation standard as a base to generate the documentation.
5. Lib: If our applications contains some Ruby libraries, those can be defined inside this folder and then called inside the part of the applications where they are supposed to be used. It also contains a folder called tasks that allows us to define Rake tasks for running inside the application.
6. Log: This contains, logs for development, test and production environment as well as for the server environment.
7. Public: All the Javascripts, images, stylesheets and application assets reside inside this folder.
8. Scripts: The Rails framework has many supporting scripts for performing various tasks inside the framework. These scripts lie inside this folder.
9. Test: Rails uses runit test as the default testing framework . Tests for controllers and models are present in the test folder of the Rails app. It also contains fixtures that help in inserting the test data for the application.
10. Tmp: As the name suggests tmp contains temporary files like sessions, cache, pids that change every time the application runs.
11. Vendor: The Rails framework can be easily extended using plug-ins. If we want to use an external API or just want to provide a standardized way to perform a particular function, we can use plug-ins.
12. README: Provides a readme file for the application.

With all the concepts, we are ready to develop our first Rails application. Thanks for stopping by and check back next week where we'll start digging into our application.