| 级别: 高级 | 
Ruby on Rails 是一个相对较新的 Web 应用程序框架,构建在 Ruby 语言之上。它被宣传为现有企业框架的一个替代,而它的目标,简而言之,就是让生活,至少是 Web 开发方面的生活,变得更轻松。在本文中,Aaron Rustad 将对 Rails 和传统的 J2EE 框架在架构上的一些关键特性进行比较。
Rails 是一个用 Ruby 编写的全栈的(full-stack)、开源的 Web 框架,可以使用它来轻松编写实际的应用程序,所需的代码也要比大多数框架花在处理 XML 上的代码少。
图 1 比较了 Rails 堆栈和典型的 J2EE Web 堆栈(包括 Tomcat servlet 容器、Struts Web 应用程序框架和 Hibernate 持久性框架)。
Struts 的
ActionServlet 和 Rails 的 DispatchServlet 都是前端控制器模式的例子;所以,它们提供了相同的功能。它们接受 HTTP 请求,解析 URL,把请求的处理转发给适当的动作。在 Struts 中,动作是扩展自 Action 的类;对于 Rails,动作是扩展自 ActionController 的类。两个前端控制器之间的主要区别是它们如何决定处理具体请求的动作。Action 类。当首次装入 ActionServlet 时,它将解析这个文件,并准备接受请求。根据约定,以 .do 结束的请求被重定向到 ActionServlet,由 ActionServlet 分派到适当的 Action。图 2 的 XML 是一个典型的映射。它告诉 ActionServlet 把叫作 controllers.order.DeleteOrderAction 作进一步处理。[url]http://localhost/order/delete/4[/url] 告诉 Rails 调用 OrderController 实例上的 delete 方法,并将 4 作为可用的实例变量。Rails 足够聪明,知道 /order 将映射到文件 order_controller.rb 中定义的一个控制器类。如果在控制器中定义了 find 方法,那么只要用 find 替代 URL 中的 delete,就可以调用这个方法。在 Rails 和 Struts 中,动作用来充当前端控制器和模型之间的桥梁。开发人员提供动作的现实,从而提供特定于应用程序的请求处理。前端控制器负责接受请求,并把请求传递到特定动作。图 3 演示了 Rails 和 Struts 基本的动作层次结构。
| 动作是模型还是控制器? Action和ActionController从技术上讲是 MVC 模式的控制器的一部分,因为它们对客户发起的事件进行响应。但是,在小型应用程序中,开发人员通常在这些类中对域或业务逻辑进行编码,所以在这些情况下,也可以把它们看作是模型的一部分。最佳实践建议:应当把域逻辑从控制器中抽象出来,放置在它自己的特定于域的类中。 | 
Action 并覆盖 execute(),以处理请求。通常,每个 Action 类都提供了非常具体的工作单元。图 3 演示了三个特定动作:SaveOrderAction、DeleteOrderAction 和 ListOrdersAction。前端控制器将调用 execute() 方法,传递给它许多有用的对象,其中包括 HTTP 请求和响应对象。ActionForm 是一个类,它可以方便地向视图来回传输并验证与表单有关的输入,ActionMapping 包含映射的配置信息,就像 图 2 的 XML 所描述的那样。execute() 方法返回 ActionForward 对象,Struts 用这个对象来确定对请求继续进行处理的组件。一般来说,这个组件是一个 JSP 页面,但是 ActionForward 也能指向其他动作。开发人员必须清楚,Struts 创建的是 Action 的单一实例,并允许多个线程调用它的 execute()。这使请求处理变得更快,因为框架处理每个请求时不用频繁地创建新的 Action 实例。但是因为可以在多个线程之间共享单一对象,所以必须遵守适当的线程注意事项,因为其他线程可能会破坏在这个动作中保持状态的实例变量。ActionController::Base,让模型参与到请求处理中。Rails 没有将 ActionController 的实例池化;相反,它为每个请求创建新的实例。虽然这对性能可能有负面影响,但是它可以让开发变得更容易。开发人员不需要关注 Struts 中存在的线程问题,因此,会话、请求、标题和参数都可以作为 ActionController 的实例成员来进行访问。ActionController 还是一个将特定域逻辑的所有处理组合在一起的合理场所。Struts 的 Action 类是细粒度的,它提供了非常具体的工作单元,而 Rails ActionController 则是粗粒度的,它将具体的工作单元模拟为一些方法。DeleteOrderAction 的 execute() 方法和 OrderController 的 delete 方法,可以看出它们基本上是相同的。| 步骤 | Struts | Rails | 
| 框架调用动作 | 行 03: execute() | 行 07: delete | 
| 从请求中检索到的 ID | 行 06-07:从请求对象中取出 | 行 08:从所有参数的实例哈希中取出 | 
| 从数据库删除订单记录 | 行 09、14-24:调用 delete()方法,用 Hibernate 删除记录 | 行 09:用 ActiveRecord 删除记录 | 
| 重定向到列出剩余订单 | 行 11:用 ActionMapping对象查找将要转发处理的下一个组件。图 2 中的 XML 映射显示,success将映射到/listOrders,这是另一个Action,负责查找剩余订单,并以 JSP 的形式呈现它们 | 行 10:用将调用的下一动作的哈希来调用 redirect_to方法;在这种情况下,它只是调用同一控制器的list方法 | 
持久性框架 用来在应用程序层和数据库之间来回移动数据。Hibernate 和 Rails 的持久性框架可以归类为对象/关系映射(ORM)工具,这意味着它们接受数据的对象视图,并将该视图映射到关系数据库内的表中。使用两种框架的目的都是为了减少与关系数据库有关的开发时间。但是,图 4 演示了两者在设计和配置上的一些根本区别。
Hibernate 基于 Data Mapper 模式,在这种模式中,特定的映射器类
Session 负责在数据库中持久存储和检索数据。Hibernate 可以持久存储任何 Java 对象,只要这个对象符合 JavaBean 规范。XML 映射文件描述了如何将类映射到数据库中具体的表,并描述了类与其他类的关系。class 标签把 Order 对象映射到 ORDERS 表,还有许多子标签用于描述其属性、ID 订单名称,以及同 models.Item 的一对多关系。清单 4 显示了 Order 类本身。|  | 
|  | 
| 反射和元编程 Wikipedia 中(请参阅 参考资料)简要地把 反射 定义为“程序在运行的时候检查和修改其高级结构的能力”。在那里,还将 元编程 定义为“编写那些能够编写和操作其他其他程序(或它们自己),将其他程序作为自己的数据的程序,或者编写那些完成其他程序在运行时所做的部分工作的程序。” 以下代码将实现反射: 
 这个代码将实现元编程: 
 | 
ActiveRecord::Base。Order 类将映射到数据库中的 ORDERS 表。使用 Ruby 反射和元编程的组合,表的列可以变成对象的属性。访问器和调整器也添加了进来。Order 类的完成后的代码。在 Order 类体中有一行代码定义了它与 Item 对象的关系。has_many 是一个静态方法调用,符号 :items 是它的参数。ActiveRecord 用 :items 发现 Item 域对象,然后将这个 Item 对象映射回数据库中的 ITEMS 表。|  | 
| 类方法 | 实例方法 | 属性 | 
| 
 | 
 | 
 | 
虽然 Ruby on Rails 是一个非常新、令人兴奋的框架,并且在 Web 社区中已经引起了人们相当的兴趣,但是它的核心架构仍然遵循在 J2EE 中发现的基本模式。开发把两个框架分开的 Web 应用程序是一种合理的方法。Rails 更喜欢清楚的代码而不是配置文件,而 Ruby 语言的动态性质在运行时生成了大部分管道 代码。大多数 Rails 框架都是作为独立项目创建的,而且应用程序开发能够从一组同类组件受益。相比之下,典型的 J2EE 堆栈倾向于构建在通常独立开发的最好的组件之上,常常用 XML 进行配置并将组件组合在一起。
 
 
                     
  
  
  
  
            
        













 
                    

 
                 
                    