Agile Web Development with Rails

Figure2.1:TheModel-View-ControllerArchitecture

be a view thatdisplaysproductinformation on a catalogpage and another set of views usedby administrators to add and editproducts.

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

Thistriumvirate.themodel,view,and controller.togetherform an architec-tureknown asMVC.Figure 2.1 showsMVCin abstract terms.

MVC was originally intended for conventional GUI applications, where devel-opersfound theseparationof concernsled tofarlesscoupling,whichinturn made the code easier to write and maintain. Each concept or action was expressedinjust one well-knownplace.UsingMVC waslike constructing a skyscraper with the girders already in place.it was a lot easier to hang the rest of thepieces 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 .rst 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,andJavaServerFaces.All arebased(with varyingdegreesof .delity) on theideas ofMVC.

Report erratum

Prepared exclusively for Jordan A. Fowler

MODELS, VIEWS, AND CONTROLLERS

Figure2.2:Rails andMVC

Ruby on Rails is an MVC framework, too. Rails enforces a structure for your application.youdevelop models, views, and controllers as separate chunks of functionality and it knits them all together as your program executes. One of thejoysofRailsisthatthisknittingprocessisbased ontheuse ofintelligent defaults so that you typically don�ft need to write any external con.guration metadata to make it all work. This is an example of the Rails philosophy of favoring convention over con.guration.

In a Rails application, incoming requests are .rst 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 identi.es a particular method(called an action in Rails parlance) somewhere in the 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 preparesinformationfor the view, whichrenders something to the user.

Figure2.2, showshowRailshandles anincoming request.Inthis example,the applicationhaspreviouslydisplayed aproduct catalogpageand the userhas just clickedthe Add To Cart button next to one of the products. This button links to http://my.url/store/add_to_cart/123, where add_to_cart is an actionin our application and123is ourinternalidfor the selectedproduct.1

1. Wecovertheformat ofRailsURLslaterinthebook.However,it�fsworthpointing outherethat havingURLsperform actions such as add to cart canbedangerous. SeeSection 21.6, TheProblem with GET Requests, onpage 462 for moredetails.

Report erratum

Prepared exclusively for Jordan A. Fowler

The routing component receives the incoming request and immediately picks it apart. In this simple case, it takes the .rst part of the path, store, as the name of the controller and the second part, add_to_cart, as the name of an action.Thelastpartofthepath, 123,isby convention extractedinto aninternal parameter called id.Asa result of all this analysis,the routerknowsithasto invoke the add_to_cart method in the controller class StoreController (we�flltalk about naming conventions onpage 240).