MVC - Model-View-Controller¶

When "talking" with a web server, a user submits a sequence of requests through her web browser. The application receives each request and reacts accordingly. This request/response orchestration can be very complicated or, more often, repetitive.

As an example, consider what could happen when a user requests a page:

• User submits the URL in her web browser, which sends a request to our web server. The web server then forwards it to the appropriate application. For the sake of simplicity, let's suppose we have just one application running.
• (1) The application checks the input submitted by the user and validates it.
• (2 and 3) The application gets data from the model and/or the database.
• (4 and 5) The application uses what is retrieved from the model and the database, along with the prepared views, to build the response.
• (6) Finally, the application sends the response to the browser.

It's easy to see a lot of repetition here: input validation, database access, and so on.

In such cases a clear definition of roles ("who does what") among objects inside our application offers a lot of advantages: each piece is responsible for a defined set of functionality. Let's see how it works.

The Model is responsible for managing the objects that define our application. Examples: books, authors, blog posts, comments, activities list, etc.

The View is responsible for making the content visible to the user. Examples include: a page containing the requested blog post with comments in the bottom, title at the top,; an email notifying a user that their account is active; an RSS feed of new blog entries, etc.

The Controller is responsible for acting as supervisor between Models and Views. A user interacts only with the controllers and receives, as responses, views containing the models' data.

Let's suppose the user request a page for a specific book's details:

• The user submits the request.
• The controller receives the request and finds the model objects needed to build the response.
• The model objects interact with database to provide the data.
• The controller passes data to a view that builds a human response.
• The controller sends the view to the user.

How is all of that represented within a Rails application?

Models reside in the <tt>app/models/</tt> directory. Each file follows the convention to be named as a singular case of the model it describes.

Example:

# app/models/book.rb
class Book < ActiveRecord::Base
end

The Book class inherits from the ActiveRecord::Base class. Such inheritance gives the Book class a lot of useful methods we'll explore later.

Of course the Book objects are stored in the database within an appropriate table. Such a table, following the Rails convention, is named books. If you could see the table in a visual format, it would look something like:

id	title	year	genre	ISBN	summary
100	Programming Ruby	2005	technical	0974514055	Ruby is a cross platform, object-oriented programming language that ...
101	Agile web development with Rails	2005	technical	097669400X	Your job is to write high quality, beautiful-looking web applications...

Objects lives in computer memory, while database tables reside (usually) on a computer's disk, and this fact makes them persistent.

Models in Rails are mapped through an Object-Relational Mapper (ORM) that maps objects (a given book, in our examples) to a specific table row (a row inside the books table).

Please notice that the attribute named id is a unique identifier needed to distinguish between objects with similar (if not identical) attributes.