2.Rails程序框架

• 模型（model）
• 视图（view）
• 控制器（controller）

Rails对Web应用的结构有着严格的约束。但是这些约束反倒使得创建应用程序变得简单。

模型

负责维持应用程序的状态。这种状态有时候是短暂的（仅用于和用户的几次交互），有时是持久的（需要将其保存在应用程序之外，如数据库中）。

模型是数据，但又不只是数据。还负责把业务规则附加在这些数据上。通过这样的设计，模型就不再只是数据的容器，还是数据的监护者。

视图

负责生成用户界面。通常根据模型中的数据来生成。

控制器

负责协调整个应用程序的运转。控制器接收外界的事件，与模型进行交互，并将合适的视图展示给用户。

Rails强制性要求应用程序按照MVC进行三个方面的划分。并遵循这个结构开发各个部分的功能。

当程序运行时，Rails会把各个部分组装在一起。
Rails的强大之处：基于约定重于配置的原则，把程序组合在一起。大大减少了配置信息的设置。

Rails程序运作流程

• 进入的请求会首先发送给一个路由器；
• 该路由器判断应该将请求发送到应用程序的什么部分以及如何解析这个请求：控制器/方法；
• 控制器中的方法将：查阅请求（URL）中的携带的数据，可以与模型交互，也可以调用别的方法。PS:一般控制器中的方法叫作action(行为)；
• 行为为视图准备充分的信息；
• 视图将所需的信息展示给用户。

Rails中的模型

一般，Web应用中的信息保存在关系数据库中。

关系数据库：基于数学中的集合理论设计，关注的是值的集合。
面向对象编程语言：关注的是数据和操作。

因此问题来了：二者很难融为一体。
如果二者能够天然的融为一体，就不会有各种各样的方法来处理二者的映射了。

一方面我们编程时，用的是OO的视角思考问题，但是在数据库存储中，编码方式不同。SQL能够表述很复杂的数据关系，到OO体系下就很难编码实现。反过来也是。

两种解决方法

• 以数据库为中心组织应用程序
• 以应用程序为中心组织数据库

ORM

将数据库表映射到类：表中的每条记录对应该类的一个对象。对象内部，属性用于读/写各个字段。

Rails类对数据库表进行了包装，提供了一组类级别的方法，用于执行表级别的操作。

order = Order.find(1) #Order是类puts "Customer #{order.customer_id}"#用类级别的方法返回一组对象集合Order.where(:name => 'dave').each do |order|    puts order.amoutend#对应表中的每行有一些方法，用于操作自己对应的那些记录#比如常用的save()Order.where(:name =>'dave').each do |order|    order.pay_type = "Purchase order"    order.saveend

总结来说就是：ORM层将：

• 数据库表映射到类
• 将记录映射到对象
• 将字段映射到对象属性
• 类方法用于执行表级别的操作
• 实例方法用于执行对单条记录的操作

缺点：不得不忙于创建和维护一大堆XML配置文件。

Rails采用的ORM: Active Record

优势：基于命名约定提供默认配置，从而大大减少了开发者实际的配置量。

require 'active_record'class Order < ActiveRecord::Baseendorder = Order.find(1)order.pay_type = "Purchase order"order.save

Action Pack:视图与控制器

MVC框架下，视图和控制器密不可分。

• 控制器为视图提供数据
• 控制器接收来自页面的事件，而页面由视图生成

基于二者如此关系，在Rails中，对视图和控制器的支持捆绑在同一个组件中：Action Pack.

视图中的动态内容

常用的有三种方式

• ERb(Embedded Ruby) : 将Ruby代码嵌入在视图文档
• XML Builder：用Ruby来构造XML文档，用到的是xml.builder模板
• RJS视图：在服务器端创建JavaScript代码，并将其传递到浏览器执行。这个方式在Ajax界面上非常常用。

控制器负责的其他任务

• 将外部请求指引到内部行为（URL）
• 负责管理缓存：为应用程序的性能带来数量级的提升
• 负责管理辅助模块：辅助模块可以扩展视图模板的功能，但是不会让视图代码膨胀
• 负责管理会话：让用户感觉与应用程序好像在持续不断的交互

–笔记自《Agile Web Development with Rails》