如果你现在正在使用Spring和Hibernate等Java框架，那就用不着改变。但如果可以灵活地为下一个项目选择新的开发方法，不妨考虑Rails。

　　遗憾的是，改用一种新语言一般被认为是危险举措，管理人员对风险有顾虑。JRuby能够让Rails更容易被管理人员所接受。在JVM上，Rails成了一种Java框架。譬如说，“Java”Web框架中的非Java语言实际上同样用于JavaServer Pages中。

　　就像通常用C/C++编写的操作系统为使用比较抽象的语言编写的应用程序提供了基础架构一样，Java平台也为Ruby等动态语言扮演“系统软件”的角色，提供了基础架构层面的支持。如今可以通过Java访问众多的功能。JDBC和Java消息服务(JMS)等API是同类中最佳的，而许多不可替代的内部或者独立软件开发商的企业信息系统可以通过Java API来访问。Rails应用程序通过使用JRuby，可以像调用Java代码那样调用现有的Java库。

　　有了JRuby，Rails应用程序可与Java Web应用程序在现有的Java EE应用服务器上一起运行。这种应用服务器拥有强大的技术基础架构。在人员和培训方面，通常不缺乏教育计划以及有经验的开发和支持人员。另外只要运行在JVM上，这种应用服务器就能够获得最近十年在JVM方面投入的许多优化项目所带来的好处。

　　JVM拥有比Ruby复杂得多的安全模型，为JRuby on Rails提供了处理Web应用程序的常见安全难题的工具，包括控制从各个来源获得的Ruby脚本。它还包含了内部支持国际化的功能。

　　向动态语言迈进，这是在抽象机制方面向更高级语言发展的一个方面。在JVM的管理环境下而不是在操作系统层面上运行Ruby解释程序又是向更高抽象层迈出的一步。使用Rails作为Web应用程序层的标准实现机制也是如此，只把针对特定应用程序的功能留给了开发人员。

　　链接：JRuby面临的难题

　　正如版本号所示，JRuby 0.9.2还没有准备好运行生产应用程序。一些错误有待解决;另外，目前JRuby的速度不如MRI。与Rails一起使用Java应用服务器需要非标准的适配器服务器小程序，而构建war文件需要特殊的Ant脚本，这两者还不是JRuby发行版的标准部分。

　　Rails在处理遗留组件方面的功能特别弱。虽然Rails为解决大多数常见问题提供了很好的支持，但缺少支持替代方案的灵活性。譬如说，活动记录假定每个表都有一个名为id的单一主键列。虽然可以用键列代替另一个名称，要是不使用特殊插件，就无法定义多列键。相比之下，Hibernate等Java框架虽然在简单(且常见)的情况下开发速度比较慢，但处理极端状况和遗留代码的效果比Rails好得多。

　　最终，采用Rails面临的主要难题在于，是否渴望现有语言和框架方面统一标准。Rails适用于这种渴望比较强烈的新项目和新组织。

 
　
说明：本教程来源互联网或网友上传或出版商，仅为学习研究或媒体推广，wanshiok.com不保证资料的完整性。
　

 2/2   首页 上一页 1 2