The Rails approach to handling requests, shown in Figure 4-4, has a lot of moving parts between users and data.
Rails handles URL processing instead of letting the web server pick which file to execute in response to the request. This allows Rails to use its own conventions for deciding how a request gets handled, called routing, and it allows developers to create their own routing conventions to meet their applications’ needs.
The router sends the request information to a controller. The controller decides how to handle the request, centralizing the logic for responding to different kinds of requests. The controller may interact with a data model (or several), and those models will interact with the database if necessary. The person writing the controller never has to touch SQL, though, and even the person writing the model should be able to stay away from it.
Once the controller has gathered and processed the information it needs, it sends that data to a view for rendering. The controller can pick and choose among different views if it needs to, making it easy to throw an XML rendering on a controller that was originally expecting to be part of an HTML-generating process. You could offer a variety of different kinds of HTML—basic, Ajax, or meant for mobile—from your applications if necessary. Rails can even, at the developer’s discretion, generate basic views automatically, a feature called scaffolding. Scaffolding makes it extremely easy to get started on the data management side of an application without getting too hung up on its presentation.
The final result comes from the view, and Rails sends it along to the user. The user, of course, doesn’t need to know how all of this came to pass—the user just gets the final view of the information, which hopefully is what they wanted.