Learning Notes about Agile Web Development with Rails (2)

Chapter 3 1. MVC architecture 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 appli- cation, often in a database. A model is more than just data; it enforces all the business rules that apply to that data. (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. 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.  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. The MVC architecture was originally intended for conventional GUI applica- tions, where developers found the separation of concerns led to far less cou- pling, which in turn made the code easier to write and maintain.  2. Rails processing flow 1) In a Rails application, an incoming request is 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.  2) The routing component receives the incoming request and immediately picks it apart.    3) Controller interacts with model 4) Controller invokes view 5) View renders next browser screen 3. Why need a framework such as Ruby on Rails?  The answer is 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. 4. Object-Relational Mapping Relational databases are actually designed around mathematical set theory. Although this is good from a conceptual point of view, it makes it difficult to combine relational databases with object-oriented (OO) program- ming languages. 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, an ORM layer maps tables to classes, rows to objects, and columns to attributes of those objects. Class methods are used to perform table-level oper- ations, and instance methods perform operations on the individual rows. Active Record Active Record is the ORM layer supplied with Rails. It closely follows the stan- dard ORM model: tables map to classes, rows to objects, and 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.  Active Record relieves us of the hassles of dealing with the underlying database, leaving us free to work on business logic. But Active Record does more than that. Active Record integrates seam- lessly with the rest of the Rails framework. If a web form sends the application data related to a business object, Active Record can extract it into our model. Active Record supports sophisticated validation of model data, and if the form data fails validations, the Rails views can extract and format errors. Active Record is the solid model foundation of the Rails MVC architecture. 5. Action Pack: The View and Controller When you think about it, the view and controller parts of MVC are pretty intimate. The controller supplies data to the view, and the controller receives events from the pages generated by the views. Because of these interactions, support for views and controllers in Rails is bundled into a single component, Action Pack.      6. View Support 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. In Rails, dynamic content is generated by templates, which come in three flavors.  1) The most common templating scheme, called Embedded Ruby (ERb), embeds snippets of Ruby code within a view document, in many ways similar to the way it is done in other web frameworks, such as PHP or JSP.  2) XML Builder can also be used to construct XML documents using Ruby code— the structure of the generated XML will automatically follow the structure of the code. 3) Rails also provides RJS views. These allow you to create JavaScript fragments on the server that are then executed on the browser. This is great for creating dynamic Ajax interfaces. 7. 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 han- dles 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.