<转>Ruby on Rails的核心特性是什么
Ruby on Rails的核心特性是什么?(1)
作者: Bruce Tate 出处:51CTO.com ( 1 ) 砖 ( 0 ) 好 评论 ( 0 ) 条 进入论坛
更新时间：2006-10-19 13:48
关 键 词：Ruby Rails 核心特性 Java
http://www.51cto.com/art/200610/33167.htm
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通过为部署和开发提供不同的环境，避免了这个问题。在开发环境中以应用程序的性能为代价强制频繁地重新加载类，而生产环境则把类的重新加载减少到最低限度，以开发人员的快速反馈周期为代价，为最终用户提供快速的体验。
交互性
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 < ApplicationControllerdef indexbreakpoint@session[:message] = "hi, mom"render_text "Showing index"enddef showrender_text @session[:message]endend
通过加载页面localhost:3000/samples和localhost:3000/samples/show来测试代码。
当Rails执行到断点时，应用程序暂停。breakpointer窗口用具有控制器当前状态的环境打开一个Ruby解释器。然后可以执行Ruby命令来查询会话的状态、执行方法和查询变量：
> puts @session[:message]-> hi, mom
这种密切联系并没有给您一个完整的调试器，但是您确实能获得Java调试器不能为您带来的功能，包括访问完整的解释器和能够执行应用程序的方法。
能够简化调试的第二个功能是Active Record控制台。Rails也附带一个脚本，能够让您在交互式Ruby解释器窗口处理持久对象。我经常想让我的Java应用程序具有这种功能。您可以编写一个持久模型，通过该模型更改数据库，然后运行一些数据库查询来看一下它们对系统的影响。要是能够在类似的设置中查询Hibernate对象就太好了。
约定优于配置
约定优于配置也会使新的Rails开发人员能够立即上手，因为控制器和模型代码特别简洁。依靠Rails环境，可以从一些非常瘦的类获得相当高级的行为——通过采用Rails命名约定和由Rails推断应用程序的连接点而不是直接配置它们。回顾一下，具有很多属性且与部门(department)具有一对多关系的Person对象可能类似于下面这样：
class Person < Active Record::Basebelongs_to :departmentend
不需要任何配置，因为Rails根据命名约定推断表(people)的名称、对象标识符和主键(id)的名称、相关的表(departments)的名称、外键(department_id)的名称、外部类(department.rb)的名称。无论对于编写、阅读还是维护来说，代码都保持简单、轻巧和非常赏心悦目。目的直接而清楚。
Java开发人员能学到什么?
我不推荐用Java语言构建一个更好的Rails。相反，Java开发人员应该从Rails框架学习一些教训，并试图构建或增强Java框架以完成下面的任务：
◆允许热部署。这将缩短开发反馈周期或支持允许热部署的框架。在Java端此优先权应该比现在高得多。
◆使用较少的XML和更多的约定。约定与配置并不是井水不犯河水，因为可以使用约定来指定明确的默认值，使用配置来覆盖约定。像Rails那样使用这种方法，您可以两全其美:具有较少重复的简洁代码而不会失去灵活性。
◆为了在调试过程中浏览Java类，合并更多的脚本语言，包括BeanShell。
◆为任务选用正确的工具。不必仅仅因为需要持久性就借助于Hibernate或仅仅因为需要Web应用程序就借助于Struts。
通过合并其他编程语言的最好特性，您可以不必重复Rails，但肯定可以改善Java体验。
作者: Bruce Tate 出处:51CTO.com ( 1 ) 砖 ( 0 ) 好 评论 ( 0 ) 条 进入论坛
更新时间：2006-10-19 13:48
关 键 词：Ruby Rails 核心特性 Java
http://www.51cto.com/art/200610/33167.htm
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通过为部署和开发提供不同的环境，避免了这个问题。在开发环境中以应用程序的性能为代价强制频繁地重新加载类，而生产环境则把类的重新加载减少到最低限度，以开发人员的快速反馈周期为代价，为最终用户提供快速的体验。
交互性
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 < ApplicationControllerdef indexbreakpoint@session[:message] = "hi, mom"render_text "Showing index"enddef showrender_text @session[:message]endend
通过加载页面localhost:3000/samples和localhost:3000/samples/show来测试代码。
当Rails执行到断点时，应用程序暂停。breakpointer窗口用具有控制器当前状态的环境打开一个Ruby解释器。然后可以执行Ruby命令来查询会话的状态、执行方法和查询变量：
> puts @session[:message]-> hi, mom
这种密切联系并没有给您一个完整的调试器，但是您确实能获得Java调试器不能为您带来的功能，包括访问完整的解释器和能够执行应用程序的方法。
能够简化调试的第二个功能是Active Record控制台。Rails也附带一个脚本，能够让您在交互式Ruby解释器窗口处理持久对象。我经常想让我的Java应用程序具有这种功能。您可以编写一个持久模型，通过该模型更改数据库，然后运行一些数据库查询来看一下它们对系统的影响。要是能够在类似的设置中查询Hibernate对象就太好了。
约定优于配置
约定优于配置也会使新的Rails开发人员能够立即上手，因为控制器和模型代码特别简洁。依靠Rails环境，可以从一些非常瘦的类获得相当高级的行为——通过采用Rails命名约定和由Rails推断应用程序的连接点而不是直接配置它们。回顾一下，具有很多属性且与部门(department)具有一对多关系的Person对象可能类似于下面这样：
class Person < Active Record::Basebelongs_to :departmentend
不需要任何配置，因为Rails根据命名约定推断表(people)的名称、对象标识符和主键(id)的名称、相关的表(departments)的名称、外键(department_id)的名称、外部类(department.rb)的名称。无论对于编写、阅读还是维护来说，代码都保持简单、轻巧和非常赏心悦目。目的直接而清楚。
Java开发人员能学到什么?
我不推荐用Java语言构建一个更好的Rails。相反，Java开发人员应该从Rails框架学习一些教训，并试图构建或增强Java框架以完成下面的任务：
◆允许热部署。这将缩短开发反馈周期或支持允许热部署的框架。在Java端此优先权应该比现在高得多。
◆使用较少的XML和更多的约定。约定与配置并不是井水不犯河水，因为可以使用约定来指定明确的默认值，使用配置来覆盖约定。像Rails那样使用这种方法，您可以两全其美:具有较少重复的简洁代码而不会失去灵活性。
◆为了在调试过程中浏览Java类，合并更多的脚本语言，包括BeanShell。
◆为任务选用正确的工具。不必仅仅因为需要持久性就借助于Hibernate或仅仅因为需要Web应用程序就借助于Struts。
通过合并其他编程语言的最好特性，您可以不必重复Rails，但肯定可以改善Java体验。