Introduction to Ruby on Rails

Ruby on Rails, often called RoR, or just Rails, is an open source web application framework written in Ruby that closely follows the Model-View-Controller (MVC) architecture. It strives for simplicity and allowing real-world applications to be developed in less code than other frameworks and with a minimum of configuration. Rails make extensive use of the metaprogramming allowed by the Ruby programming language. This use of metaprogramming allows for Rails to create a domain specific language that many programmers find to be easier to understand than traditional frameworks. Rails is primarily distributed through RubyGems, which is the official packaging format and distribution channel for Ruby libraries and applications.

Ruby on Rails MVC Architecture

The pieces of the Model-View-Controller (MVC) architecture in Ruby on Rails are as follows:

Model

In object-oriented, database-driven MVC web applications, Model consists of the classes representing RDBMS tables.

In Ruby on Rails, Model classes are handled through the Active Record. This means that for each table in database, there exists a corresponding class in the application. This class then has all functions needed to create, find, update, and delete rows in the database table. Usually, all the programmer needs to do is to subclass the ActiveRecord::Base class, and the program will automatically figure out which RDBMS table to use and what columns the table has.

For example, if there is a class Post, the following code:

a = Post.new
a.subject = "Example message"
a.body = "This is an example message."
a.save

is conceptually equivalent to the following SQL command:

INSERT INTO posts (subject, body)
VALUES ('Example message', 'This is an example message.');

and the following code:

b = Post.find(:all, :conditions => ['score > 80'])

is conceptually equivalent to the following SQL command:

SELECT * FROM posts WHERE score > 80;

The class definitions also specify the relations between classes with object-relational mapping commands. For example, if the class name Image has a definition has_many :comments, and there is an instance of Image named a, then a.comments will return an array with all Comment objects with image_id equal to a.id.

The data validation handlers (e.g. validates_uniqueness_of :checksum) and any update-related handlers (e.g. after_destroy :remove_file, before_update :update_related_details) are also specified and implemented in the model class.

View

In MVC, View is the display logic, or how the data from the Controller classes is displayed. In web applications, this frequently consists of a minimal amount of code, interspersed in HTML.

There are currently many ways the views can be handled – the underlying view code is part of the Action Pack. The method in Rails itself is to use Embedded Ruby (.rhtml files), which are basically fragments of HTML with some Ruby code interspersed, with syntax quite similar to JSP. HTML and XML can also be constructed programmatically with Builder, Liquid template system, Markaby, or Haml.

For each method in the controller that needs to display user output, a small HTML code fragment needs to be written. The page layout is described separately from the controller action that displays layouts, and the fragments can also call other fragments.

Controller

In MVC, Controller classes respond to user interaction and call the application logic, which in turn manipulates the data in Model and displays the data through View. In web-based MVC applications, the Controller methods are initiated by the user through the web browser.

Controller implementation is handled through Rails' Action Pack, which contains the class ApplicationController. Rails applications simply subclass ApplicationController and write required actions as methods, which can then be accessed through the web, typically in form of /example/method, which calls ExampleController#method, and presents the data using the view file /app/views/example/method.rhtml, unless the method redirects elsewhere.

Rails also provides out-of-the-box scaffolding, which can quickly construct most of the logic and views needed to do common operations, such as Create, Read, Update and Delete (CRUD).

Web Server Support

For development, the lightweight WEBrick web server included with Ruby is often used as the application server. For production use, Apache, Cherokee, Nginx or Lighttpd with FastCGI is recommended, but any web server with CGI or FastCGI support will work. On Apache, mod_ruby can help with performance considerably, though its use is frequently discouraged because it is unsafe to share multiple RoR applications on Apache. An almost pure-Ruby web server, Mongrel, could also be used as a quick and effective replacement of WEBrick in a development environment and is quickly gaining use as a production server as proxied by Lighttpd or Apache.

Database Support

Since the Rails architecture strongly favors database use, an RDBMS system is recommended for data storage. Rails supports the SQLite library if running an RDBMS server is not possible. The database access is entirely abstracted from the programmer's point of view, and Rails handles access to all databases automatically; though the use of direct SQL queries is possible, if necessary. Rails attempts to maintain database-neutrality, application portability over different database systems, and usability of pre-existing databases for Rails application development as much as possible, though due to different feature sets of the RDBMSes, it is not completely guaranteed by the framework alone. Several different RDBMS systems are supported, including IBM DB2, Microsoft SQL Server, MySQL, Oracle, PostgreSQL, and SQLite.

Ruby on Rails Requirements

  • Web server such as Apache 1.3.x or 2.x, nginx, lighttpd, or any FastCGI (or SCGI)-capable webserver with a mod_rewrite-like module. For development, Rails' "server" script uses WEBrick, which may be used in place of other web servers. However, WEBrick generally exhibits slow performance and is not recommended for production use. Note: FastCGI has taken a backseat in production environments to a more capable setup using Mongrel. Faster performance can be achieved using a proxy balancer and Mongrel, than can be found using FastCGI.
  • FastCGI or mod ruby for production performance. CGI is possible but quite slow.
  • Database and driver (e.g. MySQL, PostgreSQL, or SQLite).

If you haven't already, make sure you check out the Ruby programming language at Ruby Syntax.