Grails 开发团队成员 Marc Palmer 发表了一篇博客文章，针对开发人员对 Grails 常见的一些误解逐一进行了说明。例如针对“对于我来说，Grails 还不够成熟”，他这样回应：
针对这个误解，我想不断增长的商业网站数量就是最好的答案了。同时，Grails 也是基于 HIbernate、Spring 和 SiteMesh 这些成熟完善的框架构建的，更不用说作为万年常青树的 Java JDK 了。Groovy 项目都已经有超过三年的历史了。
接着，对于“Grails 使用的是一门解释型语言（Groovy）”这个误解，他谈到：
Groovy 在运行时自动编译成 Java 虚拟机字节码，它绝绝对对彻彻底底不是一门解释型语言。句号。绝不。我说了绝不了么？一点儿也没错。
最后，讨论到 Grails 是否支持 Rails 的一个克隆产物，他如是回答：
Ruby on Rails 引入了不少非常好的主意，并将它们合为一体。Grails 将其中的一部分应用到了 Groovy/Java 的世界中，但加入了许多 Ruby 中并不存在的特性和概念，所有这些东西都是以一种对 Groovy 和 Java 程序员有意义的方式展现给他们的。
Graeme Rocher 顺势而上，也提出了自己的 Grails 误解和问题列表，比如说“在我们有了 JRuby on Rails 之后，谁还要 Grails 呢？”：
这个问题很有代表性，也是对“Grails 到底是什么”最大的误解之一的根本所在。JRuby on Rails 是让 Rails 运行在像 GlassFish 这样的 Java EE 容器上非常优秀的方式之一，就是这样而已。但 Grails 的目标却大为迥异，它并不是 Rails 在 Groovy 语言上的一个移植版本，而是将业界内最为强悍的组件（比如说 Spring、Hibernate、Quartz、Compass 和 SiteMesh 等）以最佳方式组合起来的一个实践，并通过采纳无配置规约（Convention-over-Configuration，CoC）使它们符合“不重复（Don’t Repeat Yourself，DRY）”原则。 我们并不是在重造轮子，而且由于 Grails 内核的绝大部分都是以 Java 编写的，它也显得更加强壮和稳定。事实上，从内核角度看 Grails 是一个 Spring MVC 应用，可以被部署到所有的主流容器之上，不仅仅只有 Glasshfish，还有大型商业容器，比如说 WebLogic、WebSphere 和 Oracle AS。
再有，“为什么 Grails 比 Rails 更适用于企业应用？”：
原因很多，最显著的两个原因就是 Spring 和 Hibernate。到目前为止，有不计其数的组织在采用 Spring 和 HIbernate，他们都有既有的 Spring 上下文环境，以及已经构造好的 Hibernate 领域对象等。 在我开始参与 Grails 项目之前，我就经历过同样的情况。我们设计 Grails 的目的就是为了让它和这些框架尽可能无缝地整合起来。因此，我们打个比方，你可以把一个用 Java 编写的 Hibernate 领域模型及其对应的配置文件直接扔进 Grails 应用中，然后就可以使用动态的查询方法，并且直接使用 GORM 了。
此外，Grails 控制器使用了标准的 Servlet API 对象（如 request、response 和 session 等），因此可以和其它的 Servlet 一起使用。毕竟，掀起它的盖头之后，我们会发现它不过是一个 Spring MVC 应用。另一方面，Rails 几乎是按照和 EJB2 一样的方式设计的（在我发现这点时，怎一个“震惊”二字了得！）。也就是说，你在扩展 ActiveController 和 ActiveRecord 等框架对象时，你也就被绑定在了这套框架上。
在 Rails 里面根本就不存在领域模型的说法，Rails 的模型就是数据库表。这当然是一件好事了，但在企业内部，同一个领域模型可能会在许多不同的应用中服用，比如说桌面应用和 Web 应用。在 Java 里，这实际上是非常成熟完善的，通过把类对象及相应映射文件打包成一个 JAR 文件即可。
亲爱的读者，关于 Grails，您还存在什么问题吗？或者您还见过对 Grails 用途的其它误解么？请在 InfoQ 的 Java 社区与我们一同分享吧。
查看英文原文： Grails Misconceptions
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论