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 的访问进行了定制并且实现了著名的被称为 Model 2的设计策略。Rails 版本已经优化了控制器和视图之间的集成(该集成能够使配置文件最小化)并且自动使控制器实例变量可供视图使用。
- 项目目录结构:所有 Rails 应用程序都具有相同的项目结构，其中的目录用于存储应用程序代码、数据库配置、公共的静态文件，以及用于管理 Web 服务器和进行基于 Web 的功能测试的脚本。
- 架构:通过提供用于生成应用程序组件(这些组件都符合普通架构目标，比如页面级和片段级缓存;两层设计;用于测试、开发和生产的环境)的开箱即用脚本，Rails 框架简化了架构。
- 工具:Rails 工具专门用于 Web。日志支持、breakpointer、剖析器(profiler)和测试框架都针对基于 Web 的应用程序进行了修剪并针对两层操作而被启用。
但是钉子枪永远不会取代锤子，我们却愚蠢地希望能完全取代。锤子总能做一些钉子枪不能做的事情。Rails 将永远不会成为用于企业集成、对象关系映射或全堆栈 Web 服务的工具。您可以对 Rails 所做的最好期望是，它是能很好满足它所针对领域的专门工具。
开发人员实践
当您开始透过表面深入研究下去时，您开始了解 Rails 开发人员实践是如此的完全不同。快速的反馈周期、每次的交互控制和约定优于配置，这些都增强了在 Java 框架中不常用的那些方面的开发人员实践。
反馈周期
影响开发人员生产率的最重要因素之一是总体反馈周期。反馈周期是从改变代码到在屏幕上看到执行应用程序的结果所用的时间。在 Rails 中，能够在编码时得到即时的反馈。当您对 Ruby 代码做出更改时，该功能十分显著。可以立即加载一个浏览器页面来查看更改以后的结果。因为在开发期间不需要编译或部署，我倾向于在重新加载浏览器或执行测试用例之前只对编程做微小的更改。几乎每个开始使用 Rails 的 Java 开发人员都以较小的程序块进行编码。
您可能认为对开发人员实践友好的快速反馈周期不支持生产环境。毕竟，频繁地重新加载类能够获得快速反馈周期，但是会使生产应用程序变得很慢。但是 Rails 通过为部署和开发提供不同的环境，避免了这个问题。在开发环境中以应用程序的性能为代价强制频繁地重新加载类，而生产环境则把类的重新加载减少到最低限度，以开发人员的快速反馈周期为代价，为最终用户提供快速的体验。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/61746/viewspace-80652/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/61746/viewspace-80652/
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
