解析Ruby on Rails更关注生产效率

我们周围有许多框架，但是Ruby on Rails它关注的是生产效率而不是语言。本文解释了它为什么与众不同。
 
通常，开发者看重语言，却忽视了生产效率问题。为了证明这一点，只需要看看电子公告牌和论坛上的夸夸其谈，听听开发者讨论会走廊上关于X语言和Y语言对比的豪言壮语就可以知道。但是一种语言其本身并不能代表一切。开发社区已经尝试过执行对象数据库和编写一般的框架，但是这些要么就是不够主流，要么就是太复杂了。为什么我要编写另一个数据访问层和“select * from”？
关系型模型并不适合轻易地与前端集成。除了安全、驱动、SQL注入和并发，我们还必须将图形用户界面连接到数据库——一件枯燥乏味的工作。
我现在正在一个项目中使用一个对象关系映射程序，它可以有效地处理数据库层、业务层和保持层。它本质上是一个代码生成器——虽然它是一个很复杂的生成器。尽管它的确节省了我的时间，但是我还是不得不在数据库计划变化时，重新生成代码，处理生成代码中偶然的复杂缺陷，处理更长编译时间和更大的文件。
更值得注意的是，代码生成器只限于处理数据访问层和业务层后端。它们不是框架，而是生产工具。
Ruby on Rails不是一个代码生成器。它是一个真正的框架，所以你开展项目所需要的一切在里面都有。它是为数据库驱动的网络应用程序而设计的，其中包括无SQL保持机制（ActiveRecords）、模型视图控制器（MVC）结构和嵌入式代码模版等。
Ruby on Rails是一个非常复杂、巧妙和计划周密的构建网络应用程序的软件开发平台。它以两个众所周知的构建模型为基础：MVC和n级设计。它省去了许多网络编程中通常必须进行的繁重体力劳动——编写CRUD（创建、读取、更新、删除）SQL语句，连接图形用户界面、业务和数据库层和在具体对象中表达的业务逻辑。
使用了Ruby on Rails以后，我对ASP.NET（我平常的目标开发环境）的看法改变了。最近的2.0版本声明的一个目标就是要大大减少必须手写的代码的数量。虽然实现了这一点，但是奇怪的是，几乎所有的努力都花在了改进前端上，尤其是向GUI对象捆绑数据和一些非常巧妙的成型和建模。但是一个长期运行，运作不佳的保持层——Object Spaces——却没有包括在这个版本内。所以，开发者仍然要编写自定义SQL代码和数据访问层将业务对象保存到数据库，不管怎么样，基本上Object Spaces就是一个对象关系映射包，而不是一个框架。
开源力量
在语言编写者没有做出创新时，开源运动又一次掌握了主动权。除了Ruby on Rails之外， Castle和MonoRail是将Rails带到.NET平台的两个项目。这些项目帮助我们发现，Rails不等于Ruby。 Rails是一个有自己设计的框架——Ruby是一个用来执行这种设计的工具。但Ruby是一种功能强大的语言，Rails不能在其他语言中执行也是没有理由的。虽然许多人都在争论Ruby的地位（其他的第四代语言喜欢它），但是Rails的未来是光明的。
在这个方面，Ruby甚至可能是Ruby on Rails的一个障碍——不是因为它是一种不好的语言（反过来就对了），而是因为主流语言是市场的标准，这也恰恰正是Rails将要要求的。一种相反的观点则认为，Ruby on Rails可能是允许所谓的脚本语言弥漫业务软件开发领域的木马。多年复杂的通用开发平台在生产力方面实现了很小的进步，所以一种新方法可以加速成效。

存在的障碍
最近和一位顾客研究工作时，他问我是否觉得开源软件足够安全（在这里指MySQL）。我忍不住笑了起来，因为这个问题真是太老套了，但是我也很吃惊，这个问题出现在一个和Windows没有重大关系的，相对进步的中小型企业中。所以Ruby on Rails也要面对这样一个问题：在用户和没有技术背景的决策制定者之间存在难以克服的不信任感——而决策者通常正是受益最多的人。
这就是Ruby（和Rails）社区的优势。有组织良好和专业的网络来为产品提供支持和后援。他们的高标准Web网站和文档也不是在所有开源软件中都能见到的。
对于Ruby on Rails来说，不可否认的难题就是禁止了其他软件平台，尤其是Java和PHP。Rails中至少已经有两种途径可以接入PHP——Cake和Biscuit。
一个有充分根据的问题可能是：为什么要学习Ruby以代替PHP？可能是因为，Java 和.NET项目的过度建设和多次失败使人筋疲力尽，PHP正逐渐占据企业市场。如果是这样的话，为什么要用Ruby，尤其是在取得PHP技能还相对便宜的时候？
速度
对于快速建立原型来说，Rails是一个理想的平台。数据库中的变化可以立即在业务对象中反映出来，而不需要写代码。这是通过ActiveRecord的理念实现的——框架代码自动将业务对象和数据库连接起来。这种方法通过整合到一个MVC架构中得到了进一步发展——模型组件是ActiveRecord，并且它被视图和控制器层使用。
视图也是自动生成的。一旦你将对象连接起来，框架会为你提供一个处理简单CRUD选项的默认web界面。可能这个在有限的情况下是够用的（例如，开发或少数用户访问的原型），但是几乎可以肯定的是，它需要进一步美化。Rails产生的默认HTML在生产语境中并不是随处可用的；并且它不能被用户化，只能被替换。这就要求用新的视图替代内置的视图层，并转换控制器，使其指向这些新查看。
进展中的工作
这个框架也不是万能药——开发者还有很多工作要做。例如，自动将业务对象连接到数据库表是一个很好的特性，但是完美的数据结构不能比最初设计改变太大。如果你没有使用默认的线型架构视图（在Rails中叫脚手架），那么改变数据库或许也需要更新视图和控制器。但是，Ruby on Rails通过应用程序的自动化和保证该应用程序按照逻辑构造，改进了可维护性和可拓展性。
因此，Ruby on Rails不是一个软件开发过程的完全自动化；实际上这是Ruby on Rails最好的特征之一——它没有尽力太多，对开发施加太多控制。控制度和灵活性是对立的设计目标，Ruby on Rails通过可靠的应用程序设计模式在两者之间达到了很好的平衡。
但是，越来越清醒地认识到，主流语言的所有者缺乏先见之明，他们似乎总是被语言需要所困扰，而不是应用语言去解决业务问题。
即使没有被广泛接受，Ruby on Rails社区也将保持软件强大和可行，并产生很多模仿者，也许还会留下一笔更大的遗产：重新思索一下对Java和.NET这样不断臃肿的、通用的和昂贵的开发平台的盲目依赖。Ruby on Rails却消瘦、现代和专业——它是一个框架，而不是一个平台，而且它的原理应该会为使用它的人的投资带来更高的回报。

自由
Rails不强迫开发者走一条由框架任意决定的道路。它所基于的实践——MVC、阶层分离、数据库设计——都是广泛接受的极好实践。Rails是一个由日益成熟的（Web）软件开发产业使之成为可能的产物。通过试验和犯错，我们已经发现了做事情的最佳方法，Rails就体现了这其中的许多。通过对我们的设计做出要求（例如，那些称做plurally的表格），Rails可以修改任何由数据库驱动的web应用程序的基础。这些要求可以起限制作用——例如，我经常用名词的单数形式命名表格——但是这些限制是以极好的实践和来之不易的经验为基础的，所以这些问题不那么费力。
漏掉了一点就是表示层中的真正的面向对象。Ruby on Rails的模版系统是灵活和标准的（利用专门的标记向HTML中嵌入代码），但是仍然符合程序；还有一个帮助函数，可以用来满足构建web应用程序的一般要求，像创建一个下拉选单或退出HTML。一些这样的函数的名称比较难，但是挖掘一下也会发现。一个需要改进的地方就是在视图中定义的对象在控制器或模型的代码中应该也是可用的——和ASP.NET是一样的。这将为数据绑定、数据式样和对象绑定提供大量机会。这将进一步提高Ruby on Rails自动操作繁重体力劳动的能力。
虽然我没有看过，但是关于部署用Ruby on Rails构建的应用程序过于复杂的博客讨论有很多。
甚至还有一个开源项目专门用来部署Rails应用程序。
虽然Tim O’Reilly在Ruby on Rails网站上对其称赞有加，说这项技术“降低了进入编程领域的门槛”，但是这个框架并不适合初学者。Ruby很复杂，并且虽然MVC是经过试验而且是正确的，但是对一个网络新手来说，它还是有一定难度的。我在装有Windows XP的机器上创建Rails堆栈碰到过很多问题。问题不是Rails本身，而是和一个生产web服务器集成——我尝试了Apache和IIS，最后用了Rails自带的WEBrick。但是，不推荐在生产环境中使用WEBrick。
还有另一个选择：独立安装堆栈——一个完整、单独的目录分区包括Ruby、Rails、MySQL和Apache。这在开发中比较有用，但可能不适用于web和数据库服务器通常用于多个应用程序的生产中。
要从Rails得到最多，我认为你一定已经受够了太多的数据访问层，太多的没有逻辑性的程序代码和硬接入要求的参数，和业务层的存储过程和数据库逻辑。你一定和可怕的ASP应用程序斗争过，并且要依靠过度复杂、配置驱动的重型框架，如果听起来像你是碰到过的难题，那么你会喜欢Rails的。

责任编辑:德东
查看本文的国际来源

, Special to Builder AU