Back in 1979, Trygve Reenskaug came up with a new architecture for developing interactive applications. In his design, applications were broken into three types of components: models, views, and controllers.

The model is responsible for maintaining the state of the application. Some times this state is transient, lasting for just a couple of interactions with the user. Sometimes the state is permanent and will be stored outside the application, often in a database.

A model is more than just data; it enforces all the business rules that apply to that data. For example, if a discount shouldn’t be applied to orders of less than $20, the model will enforce the constraint. This makes sense; by putting the implementation of these business rules in the model, we make sure that nothing else in the application can make our data invalid. The model acts as both a gatekeeper and a data store.

The view is responsible for generating a user interface, normally based on data in the model. For example, an online store will have a list of products to be displayed on a catalog screen. This list will be accessible via the model, but it will be a view that formats the list for the end user. Although the view may present the user with various ways of inputting data, the view itself never handles incoming data. The view’s work is done once the data is dis- played. There may well be many views that access the same model data, often for different purposes. In the online store, there’ll be a view that displays product information on a catalog page and another set of views used by ad- ministrators to add and edit products.

Controllers orchestrate the application. Controllers receive events from the outside world (normally user input), interact with the model, and display an appropriate view to the user.

This triumvirate—the model, view, and controller—together form an architecture known as MVC. To learn how the three concepts fit together, see the following figure:


Ruby on Rails is an MVC framework. Rails enforces a structure for your application—you develop models, views, and controllers as separate chunks of functionality, and it knits them all together as your program executes. One of the joys of Rails is that this knitting process is based on the use of intelligent defaults so that you typically don’t need to write any external configuration metadata to make it all work. This is an example of the Rails philosophy of favoring convention over configuration.

MVC in Rails 4


The Model

Active Record is the solid model foundation of the Rails MVC architecture.

In general, we’ll want our web applications to keep their information in a relational database. But objects are all about data and operations, and databases are all about sets of values. Operations that are easy to express in relational terms are sometimes difficult to code in an OO system. The reverse is also true.

So mapping relational data onto objects brings out. Active Record is the ORM layer supplied with Rails:

  • it closely follows the standard ORM model:
    • tables map to classes.
    • rows to objects.
    • columns to object attributes.
  • It differs from most other ORM libraries in the way it is configured:
    • By relying on convention and starting with sensible defaults, Active Record minimizes the amount of configuration that developers perform.


Continue reading: Active Record in Rails 4.

The View and Controller

Rails bunlde support for views and controllers into a single component, Action Pack, because of the interactions between actions and views.

The View

In Rails, the view is responsible for creating either all or part of a response to be displayed in a browser, processed by an application or sent as an email. At its simplest, a view is a chunk of HTML code that displays some fixed text. More typically you’ll want to include dynamic content created by the action method in the controller.


Continue reading: Action View in Rails 4.

The Controller

The Rails controller is the logical center of your application. It coordinates the interaction between the user, the views, and the model. However, Rails handles most of this interaction behind the scenes; the code you write concentrates on application-level functionality. This makes Rails controller code remarkably easy to develop and maintain.

The controller is also home to a number of important ancillary services:

  • It is responsible for routing external requests to internal actions. It handles people-friendly URLs extremely well.
  • It manages caching, which can give applications orders-of-magnitude performance boosts.
  • It manages helper modules, which extend the capabilities of the view templates without bulking up their code.
  • It manages sessions, giving users the impression of ongoing interaction with our applications.


Continue reading: Action Dispatcher and Action Controller in Rails 4.


blog comments powered by Disqus


27 November 2013