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可能是允许所谓的脚本语言弥漫业务软件开发领域的木马。多年复杂的通用开发平台在生产力方面实现了很小的进步，所以一种新方法可以加速成效。