在Java社区关于Ruby On Rails的争论已经相当激烈并且在将来一段时间没有停止的迹象。Rails的支持者称赞它的惊人的效率,与Java开发相比效率大约是10:1。作为Java程序员,您下意识的反应是不相信任何宣传过高的效率,因为您可能以前听到过这些,然而实际让您很失望。
Java 提倡者日益坚持Ruby on Rails是一个玩具,不能伸缩,会生成坏的代码,并且只能开发简单的应用程序。但是随着对Rails的赞扬不断出现(通常来自可信的来源),一项更加谨慎的任务是理解Rails能做好什么事情,并把它的思想带回到Java平台。在本文中,将探究为Rails带来巨大效率的核心特性(即秘笈)。
Rails基本原理
Ruby on Rails框架不是大家所想的典型的应用程序开发框架。Rails 的创始人 David Heinemeier Hansson 通常把该框架称为固执己见的软件,并且他喜欢打破长期存在的约定。David 做出了非常有哲理性的决策并在整个框架中严格遵循这些决策。遍布于 Rails 内的核心观点有:
◆无缝集成:Rails 聪明地利用了 Ruby 语言的***特性。它扩展了 Ruby,但您很难说出 Ruby 在哪里结束,Rails 从哪里开始。您也可以看到 Active Record(Rails 的持久引擎)和模型-视图-控制器(MVC)框架之间进行了很好的集成。例如,您可以编写三行代码,创建一个表,然后立即为该模型生成用户界面。
◆约定优于配置:为保持良好的灵活性,Java 框架保持了大量普遍的配置文件。Rails 不采用这种策略。它为方法、类、表和列采用普通的项目目录结构和简单普通的命名约定,以推断哪些已配置在 Java 应用程序中。结果是,Rails 应用程序只需要对应 Java 应用程序的一小部分配置代码,一般是十分之一或更多。
◆低重复:不要重复自己(Don't Repeat Yourself,DRY)是 Rails 社区的一个常见术语。Rails框架委员会使用通常看起来像是 Ruby 语言的扩展的方法来把重复的任务抽象出来。正如您在本系列的 第三篇文章 中看到的,Rails 的元编程策略使每行代码都执行更多的任务。
◆即时反馈:使用Rails,对于您所做的大多数工作都会给出即时反馈。编写一行代码并保存后,在加载下一个Web页面时将激活您所做的更改。更新了您的数据库以后,迁移可以向您即时显示更改。
实践基础
Ruby on Rails底层的观点全都建立在实际经验的基础上。Rails框架是从开发受欢迎的Basecamp项目管理应用程序时的实际使用经验成长起来的。
专注于某个领域
反对其宣称的过高生产率的争论通常类似于这样:如果获得了一把好的锤子,就很难找到另外一把生产率达到两倍的锤子,更不用说把生产率提高 5 到 10 倍了,因为锤子已经发展演变几千年了。但是把Ruby on Rails与各种通用目的的Java框架相比较的人是不得要领的。
通过从根本上改变工具的本质可以在某些方面提高 10 倍的生产率。现在专业的制造者使用钉子枪能够在用锤子钉入一颗钉子的时间内钉入很多钉子。像钉子枪一样,Rails 也是有专门用途的。它是一个专门编写来用于单个领域的框架:新的支持数据库的Web应用程序。
我猜想现今构建的应用程序有一半是支持数据库且基于 Web 的应用程序。所以 Rails 是明确针对某领域的产品,但是这个领域很大也很重要。专攻此领域使 Rails 具有巨大的优势,引起巨大轰动。通过专注于此领域的项目,Rails 的设计者可以选择一些其他框架不能或者不应该采用的捷径。这种专门化往往为简单性而失去灵活性。
基于Web的应用程序允许一组相似的优化。当您知道一个应用程序是基于Web的,您就能知道应用程序的大体结构和可能需要的主要组件。因为Rails关注的是基于Web的应用程序,所以在 Rails 中增强了以下功能:
◆模型-视图-控制器:Rails的MVC框架(称为 Action Pack)为基于 Web 的访问进行了定制并且实现了著名的被称为Model 2的设计策略。Rails版本已经优化了控制器和视图之间的集成(该集成能够使配置文件最小化)并且自动使控制器实例变量可供视图使用。
◆项目目录结构:所有 Rails 应用程序都具有相同的项目结构,其中的目录用于存储应用程序代码、数据库配置、公共的静态文件,以及用于管理Web服务器和进行基于Web的功能测试的脚本。
◆架构:通过提供用于生成应用程序组件(这些组件都符合普通架构目标,比如页面级和片段级缓存;两层设计;用于测试、开发和生产的环境)的开箱即用脚本,Rails框架简化了架构。
◆工具:Rails 工具专门用于 Web。日志支持、breakpointer、剖析器(profiler)和测试框架都针对基于Web的应用程序进行了修剪并针对两层操作而被启用。但是钉子枪永远不会取代锤子,我们却愚蠢地希望能完全取代。锤子总能做一些钉子枪不能做的事情。Rails将永远不会成为用于企业集成、对象关系映射或全堆栈 Web 服务的工具。您可以对 Rails 所做的***期望是,它是能很好满足它所针对领域的专门工具。
#p#
开发人员实践
当您开始透过表面深入研究下去时,您开始了解 Rails 开发人员实践是如此的完全不同。快速的反馈周期、每次的交互控制和约定优于配置,这些都增强了在 Java 框架中不常用的那些方面的开发人员实践。
反馈周期
影响开发人员生产率的最重要因素之一是总体反馈周期。反馈周期是从改变代码到在屏幕上看到执行应用程序的结果所用的时间。在Rails中,能够在编码时得到即时的反馈。当您对Ruby代码做出更改时,该功能十分显著。可以立即加载一个浏览器页面来查看更改以后的结果。因为在开发期间不需要编译或部署,我倾向于在重新加载浏览器或执行测试用例之前只对编程做微小的更改。几乎每个开始使用Rails的Java开发人员都以较小的程序块进行编码。
您可能认为对开发人员实践友好的快速反馈周期不支持生产环境。毕竟,频繁地重新加载类能够获得快速反馈周期,但是会使生产应用程序变得很慢。但是Rails通过为部署和开发提供不同的环境,避免了这个问题。在开发环境中以应用程序的性能为代价强制频繁地重新加载类,而生产环境则把类的重新加载减少到***限度,以开发人员的快速反馈周期为代价,为最终用户提供快速的体验。
交互性
Ruby的交互式体验也有助于Rails。您可能认为在没有完整的IDE的情况下调试Rails应用程序将是一个痛苦的过程。实际却不是这样。Rails提供两种简化调试的功能。其中之一是breakpointer,它允许您向源代码添加breakpoint关键字。
为理解breakpointer的运行过程,可创建一个简单的Rails应用程序,生成一个控制器,启动服务器,并启动breakpointer。确保您有权使用breakpointer窗口,因为当Ruby遇到断点时您将使用它。使用Windows时,命令序列如下:
- >rails sample
- >cd sample
- >ruby script/generate controller samples
- >start ruby script\server
- >start ruby script\breakpointer
如果在 UNIX® 或 Mac OS X 中运行,请确保服务器在一个单独的进程中启动。把以下代码键入或粘贴到app/controllers/samples_controller.rb文件中:
- class SamplesController < ApplicationController
- def index
- breakpoint
- @session[:message] = "hi, mom"
- render_text "Showing index"
- end
- def show
- render_text @session[:message]
- end
- end
通过加载页面localhost:3000/samples和localhost:3000/samples/show来测试代码。当Rails执行到断点时,应用程序暂停。breakpointer窗口用具有控制器当前状态的环境打开一个Ruby解释器。然后可以执行Ruby命令来查询会话的状态、执行方法和查询变量:
- > puts @session[:message]
- -> hi, mom
这种密切联系并没有给您一个完整的调试器,但是您确实能获得 Java 调试器不能为您带来的功能,包括访问完整的解释器和能够执行应用程序的方法。
约定优于配置
约定优于配置也会使新的Rails开发人员能够立即上手,因为控制器和模型代码特别简洁。回顾一下,具有很多属性且与部门(department)具有一对多关系的Person对象可能类似于下面这样:
- class Person < Active Record::Base
- belongs_to :department
- end
不需要任何配置,因为Rails根据命名约定推断表 (people) 的名称、对象标识符和主键 (id) 的名称、相关的表 (departments) 的名称、外键 (department_id) 的名称、外部类 (department.rb) 的名称。无论对于编写、阅读还是维护来说,代码都保持简单、轻巧和非常赏心悦目。目的直接而清楚。
#p#
Java开发人员能学到什么?
这里我不推荐用Java语言构建一个更好的Rails。相反,Java开发人员应该从Rails框架学习一些教训,并试图构建或增强Java框架以完成下面的任务:
◆允许热部署,这将缩短开发反馈周期或支持允许热部署的框架。在Java端此优先权应该比现在高得多。
◆使用较少的XML和更多的约定。约定与配置并不是井水不犯河水,因为可以使用约定来指定明确的默认值,使用配置来覆盖约定。像 Rails 那样使用这种方法,您可以两全其美:具有较少重复的简洁代码而不会失去灵活性。为了在调试过程中浏览Java类,合并更多的脚本语言,包括BeanShell。
◆为任务选用正确的工具。不必仅仅因为需要持久性就借助于Hibernate或仅仅因为需要Web应用程序就借助于Struts。通过合并其他编程语言的***特性,您可以不必重复Rails,但肯定可以改善Java体验。
原文链接:http://www.ibm.com/developerworks/cn/java/j-cb05096.html
【编辑推荐】