In this conclusion to a three-part series on the Rails framework, you'll learn how it utilizes the model-view-controller pattern, and how that pattern works. This article is excerpted from chapter one of the book Beginning Rails: From Novice to Professional, written by Jeffery Allan Hardy, Cloves Carneiro Jr. and Hampton Catlin (Apress, 2008; ISBN: 1590596862).
The MVC Pattern in the Rails Framework (Page 1 of 4 )
The MVC Pattern
Rails employs a time-honored and well-established architectural pattern that advocates a division of application logic and labor into three distinct categories: the model, view, and controller. In the MVC pattern, the model represents the data, the view represents the user interface, and the controller directs all the action. The real power lies in the combination of the MVC layers, which is something that Rails handles for you. Place your code in the right place and follow the naming conventions, and everything should fall into place.
Each part of the MVC—the model, view, and controller—is a separate entity, capable of being engineered and tested in isolation. A change to a model need not affect the views; likewise, a change to a view should have no effect on the model. This means that changes in an MVC application tend to be localized and low impact, easing the pain of maintenance considerably, while increasing the level of reusability among components.
Contrast this to the situation that occurs in a highly coupled application that mixes data access, business logic, and presentation code (PHP, we’re looking at you). Some folks call this spaghetti code because of its striking resemblance to a tangled mess. In such systems, duplication is common, and even small changes can produce large ripple effects. MVC was designed to help solve this problem.
MVC isn’t the only design pattern for web applications, but it does happen to be the one that Rails has chosen to implement. And it turns out that it works great for web development. By separating concerns into different layers, changes to one of them don’t have an impact on the others, resulting in faster development cycles and easier maintenance.
The MVC Cycle
Although MVC comes in different flavors, control flow generally works as follows (see Figure 1-1):
The user interacts with the interface and triggers an event (for example, submits a registration form).
The controller receives the input from the interface (for example, the submitted form data).
The controller accesses the model, often updating it in some way (for example, by creating a new user with the form data).
The controller invokes a view that renders an updated interface (for example, a “welcome” screen).
The interface waits for further interaction from the user, and the cycle repeats.
Figure 1-1.The MVC cycle
If the whole MVC concept sounds a little involved at first, don’t worry. While entire books could be written on this pattern, and people will argue over its purest implementation for all time, you’ll find that it’s really quite easy to grasp, especially the way Rails does MVC.
Next, we’ll take a quick tour through each letter in the MVC, and then describe how Rails handles it.