|
这就是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自动操作繁重体力劳动的能力。
|
| 共3页: 上一页 [1] 2 [3] 下一页 |
评论加载中…
