Ruby on Rails好像一直处于争论的风口浪尖。大多数争论的核心是其所宣称的令人惊异的生产力。作者Bruce Tate已经开始理解Rails并不是一个更好的工具，而是一个不同类型的工具。本文研究了使Rails在某个领域如此高效率的折衷和设计决策。然后思索了应该在Java™社区获得更多关注的受Rails启发的思想。
Ruby on Rails(也叫做Rails)是一个针对支持数据库的Internet应用程序的Ruby框架。我现在已经将Rails用于两个不同的应用程序并涉及了另外两个关联的程序。为了即将完成的新书Java to Ruby，我已经采访了很多Rails开发人员(那些在该框架上既成功也失败过的人)、框架的创始人和Rails书籍的旗舰之作Agile Web Development with Rails的主要作者。我开始理解为什么Ruby on Rails架构如此成功？
炒作和怀疑论
在Java社区关于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页面时将激活您所做的更改。更新了您的数据库以后，迁移可以向您即时显示更改。
专注于某个领域
反对其宣称的过高生产率的争论通常类似于这样：如果获得了一把好的锤子，就很难找到另外一把生产率达到两倍的锤子，更不用说把生产率提高5到10倍了，因为锤子已经发展演变几千年了。但是把Ruby on Rails与各种通用目的的Java框架相比较的人是不得要领的。通过从根本上改变工具的本质可以在某些方面提高10倍的生产率。现在专业的制造者使用钉子枪能够在用锤子钉入一颗钉子的时间内钉入很多钉子。
像钉子枪一样，Rails也是有专门用途的。它是一个专门编写来用于单个领域的框架：新的支持数据库的Web应用程序。
我猜想现今构建的应用程序有一半是支持数据库且基于Web的应用程序。所以Rails是明确针对某领域的产品，但是这个领域很大也很重要。专攻此领域使Rails具有巨大的优势，引起巨大轰动。通过专注于此领域的项目，Rails的设计者可以选择一些其他框架不能或者不应该采用的捷径。这种专门化往往为简单性而失去灵活性。
新的支持数据库的应用程序建议打包方法优于映射方法。Rails工具采用数据模型中的约定。Rails应用程序需要Java应用程序中创建的一小部分模型代码。如果特别为Rails应用程序创建模式，此原则能工作得很好。如果试图把遗留的模式塞入Rails中，将变得不太平滑。
基于Web的应用程序允许一组相似的优化。当您知道一个应用程序是基于Web的，您就能知道应用程序的大体结构和可能需要的主要组件。因为Rails关注的是基于Web的应用程序，所以在Rails中增强了以下功能：
◆模型-视图-控制器
Rails的MVC框架(称为Action Pack)为基于Web的访问进行了定制并且实现了著名的被称为Mode l2的设计策略。Rails版本已经优化了控制器和视图之间的集成(该集成能够使配置文件最小化)并且自动使控制器实例变量可供视图使用。
◆项目目录结构
所有Rails应用程序都具有相同的项目结构，其中的目录用于存储应用程序代码、数据库配置、公共的静态文件，以及用于管理Web服务器和进行基于Web的功能测试的脚本。
◆架构
通过提供用于生成应用程序组件(这些组件都符合普通架构目标，比如页面级和片段级缓存、两层设计、用于测试、开发和生产的环境)的开箱即用脚本，Rails框架简化了架构。
◆工具
Rails工具专门用于Web。日志支持、breakpointer、剖析器(profiler)和测试框架都针对基于Web的应用程序进行了修剪并针对两层操作而被启用。
但是钉子枪永远不会取代锤子，我们却愚蠢地希望能完全取代。锤子总能做一些钉子枪不能做的事情。
Rails将永远不会成为用于企业集成、对象关系映射或全堆栈Web服务的工具。您可以对Rails所做的最好期望是，它是能很好满足它所针对领域的专门工具。
开发人员实践
当您开始透过表面深入研究下去时，您开始了解Rails开发人员实践是如此的完全不同。快速的反馈周期、每次的交互控制和约定优于配置，这些都增强了在Java框架中不常用的那些方面的开发人员实践。
反馈周期
影响开发人员生产率的最重要因素之一是总体反馈周期。反馈周期是从改变代码到在屏幕上看到执行应用程序的结果所用的时间。在Rails中，能够在编码时得到即时的反馈。当您对Ruby代码做出更改时，该功能十分显著。可以立即加载一个浏览器页面来查看更改以后的结果。因为在开发期间不需要编译或部署，我倾向于在重新加载浏览器或执行测试用例之前只对编程做微小的更改。几乎每个开始使用Rails的Java开发人员都以较小的程序块进行编码。
您可能认为对开发人员实践友好的快速反馈周期不支持生产环境。毕竟，频繁地重新加载类能够获得快速反馈周期，但是会使生产应用程序变得很慢。但是Rails通过为部署和开发提供不同的环境，避免了这个问题。在开发环境中以应用程序的性能为代价强制频繁地重新加载类，而生产环境则把类的重新加载减少到最低限度，以开发人员的快速反馈周期为代价，为最终用户提供快速的体验。
| 共2页: 1 [2] 下一页 |