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却消瘦、现代和专业——它是一个框架，而不是一个平台，而且它的原理应该会为使用它的人的投资带来更高的回报。