The Architecture of Rails

The Architecture of Rails Applications

One of the interesting things about Rails is that it imposes some fairly
serious constraints on how you structure your web applications. These constraints make it easier to create applications—a lot easier.

Models, Views, and Controllers

The model is responsible for maintaining the state of the application. model Sometimes 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. 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 view on data in the model.
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 displayed. 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 administrators to add and edit products. Controllers orchestrate the application. Controllers receive events from the Controllers ouside world (normally user input), interact with the model, and display an appropriate view to the user. This triumvirate—the model, view, and controller—form an architecture known as MVC.

MVC was originally intended for conventional GUI applications, where developers found the separation of concerns led to far less coupling, which in turn made the code easier to write and maintain. Each concept or action was expressed in just one well-known place. Using MVC was like constructing a skyscraper with the girders already in place—it was a lot easier to hang the rest of the pieces with a structure already there. In the software world, we often ignore good ideas from the past as we rush headlong to meet the future. When developers first started producing web applications, they went back to writing monolithic programs that intermixed presentation, database access, business logic, and event handling in one big ball of code. But ideas from the past slowly crept back in, and folks started experimenting with architectures for web applications that mirrored the 20-year-old ideas in MVC. The results were frameworks such as WebObjects, Struts, and JavaServer Faces. All are based (with varying degrees of fidelity) on the ideas of MVC. Ruby on Rails is an MVC framework, too. Rails enforces a structure for your application where you develop models, views, and controllers as separate chunks of functionality—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.

In a Rails application, incoming requests are first sent to a router, which works out where in the application the request should be sent and how the request itself should be parsed. Ultimately, this phase identifies a particular method (called an action in Rails parlance) somewhere in the action controller code. The action might look at data in the request itself, it might interact with the model, and it might cause other actions to be invoked.

Eventually the action prepares information for the view, which renders something to the user. The routing component receives the incoming request and immediately picks it apart. In this simple case, it takes the first part of the path, store, as the name of the controller and the second part, add_to_cart, as the name of an action. The last part of the path, 123, is by convention extracted into an internal parameter called id. As a result of all this analysis, the router knows it has to invoke the add_to_cart( ) method in the controller class StoreController

The add_to_cart( ) method handles user requests. In this case it finds the current user’s shopping cart (which is an object managed by the model). It also asks the model to find the information for product 123. It then tells the shopping cart to add that product to itself. (See how the model is being used to keep track of all the business data; the controller tells it what to do, and the model knows how to do it.)
Now that the cart includes the new product, we can show it to the user.
The controller arranges things so that the view has access to the cart object
from the model, and invokes the view code. In Rails, this invocation is often
implicit; again conventions help link a particular view with a given action.
That’s all there is to an MVC web application. By following a set of conventions
and partitioning your functionality appropriately, you’ll discover
that your code becomes easier to work with and your applications becomes
easier to extend and maintain. Seems like a good trade.
If MVC is simply a question of partitioning your code a particular way, you
might be wondering why you need a framework such as Ruby on Rails.
The answer is pretty straightforward: Rails handles all of the low-level
housekeeping for you—all those messy details that take so long to handle
by yourself—and lets you concentrate on your application’s core functionality.
Let’s see how....