Grails vs Roo - 为什么 SpringSource 推动两种非常相似的技术？答案

【问题标题】：Grails vs Roo - why SpringSource is pushing two very similar technologies?Grails vs Roo - 为什么 SpringSource 推动两种非常相似的技术？
【发布时间】：2011-01-01 13:23:40
【问题描述】：

SpringSource（现在的 VMWare）有两种非常相似的技术：Grails 和 Spring Roo。我一直在使用 Grails，但我看到 SpringSource 正在积极开发该技术的竞争对手，这让我对 Grails 的未来感到担忧。

有谁知道这些技术之间的关系，它们会被合并，还是其中一种会被放弃？

此外，Grails 和 Roo 之间是否存在任何重要的技术差异？

【问题讨论】：

标签： grails spring-roo

【解决方案1】：

我们有一个需求，我们有一个生产应用程序，并且是在 Spring MVC 中开发的，并且开发新功能的速度很慢。我们不得不探索像 Grails 和 Roo 这样的替代框架。我个人花了将近一个月的时间来探索哪个更好。

如果想查看分析详情请访问@http://krishnasblog.com/2012/05/08/roo-vs-grails/

我们在这两个方面探索了以下功能，以下是我们的发现。最终判决我们不确定是否会使用其中一个，我们仍在探索中

【讨论】：

对不起，亚历克斯，我修复了链接，请查看让我知道。谢谢

【解决方案2】：

主要区别在于 Roo 是一个纯 Java 框架，而 Grails 利用了 Groovy 和 Java。两者都建立在核心 Spring 库之上，并利用流行的 Java 开源库。

这个问题在 Roo 发布时被问到，Graeme Rocher（Grails 负责人）说这两个框架都在 Spring 中占有一席之地，并且受到同等支持。

如果有的话，我认为 Grails 的未来比 Roo 更光明。我喜欢使用它进行开发，并且不认为它不是纯 Java 有任何缺点。

【讨论】：

感谢您的回答，Ben Alex 的回答证实了您所写的内容，并提供了有关 Grails 与 Roo 问题的 SpringSource 视图的更多详细信息。

【解决方案3】：

我在 Grails 邮件列表中看到了一些 cmets，它们表明作者认为 Roo 只是作为 Grails 的垫脚石存在的！但是，我个人正在考虑可能从 Grails 切换到 Roo。我认为主要区别在于动态类型语言和静态类型语言之间 - 对我来说这是巨大的。我喜欢 Grails 的许多特性，但我更喜欢静态类型语言的 IDE 支持和编译时检查。其他一些人的感觉恰恰相反，因此课程的马匹。也就是说，静态 groovy 目前正在大力发展，所以谁知道未来会怎样。

【讨论】：

【解决方案4】：

SpringSource 的目标是让人们尽可能快速、轻松地构建、运行和管理基于 Spring 的解决方案。我们同时拥有 Grails 和 Spring Roo，因为我们非常关心开发人员的工作效率，而且毫无疑问，这两种工具都极大地促进了团队在 Spring 之上可以实现的目标。

我们拥有这两种技术，因为 Roo 和 Grails 在哲学和实施层面上非常不同（正如其他回复中已经指出的那样）。每种技术都以“我们如何使用这种语言和操作模型的组合使价值主张变得难以置信的好？”的理念来处理其主要语言（Java 或 Groovy）和操作模型（开发时或运行时）。因此，您将看到每种技术采用不同的风格，最大限度地发挥这种组合（Roo 的 Java+Dev-time 或 Grail 的 Groovy+Runtime）和相应的好处。

这些差异实际上是非常积极的，因为它们意味着 Spring 社区可以选择他们喜欢的生产力解决方案的“风格”。虽然围绕语言选择和运行时/开发时操作的这些初始差异立即显而易见，但 Grails 或 Roo 的选择还扩展到更微妙的考虑因素，例如使用的默认技术、用户交互模型、IDE 支持、依赖关系、标准、路线图、扩展等。几乎所有这些差异都是为特定语言风格寻求最佳解决方案的自然结果。

我们最好的建议是同时考虑这两种解决方案。每个都有自己的最佳点，但两者之间存在差异，这将使您在特定环境中使用一种技术或另一种技术获得更好的整体体验。两个参考指南都详细介绍了each solution 的respective benefits。当然，请记住尝试两者的时间投资是最小的。在 10 分钟内，您就可以在 Roo 或 Grails 中构建一个项目，因此请试一试，看看根据您的特定背景和项目需求，哪些对您来说更自然。

【讨论】：

非常感谢您的深入解答！
10 分钟？我花了将近 10 个小时来编译 1.1.1 GAE 和 GWT 费用样本（更不用说工作了）。究竟引入了哪些 GAE 数据存储增强功能？以及如何使用它们？我很困惑，并且真的开始质疑 SpringSource 的 QA 流程......添加一个 JUnit 对所有 roo 样本执行 roo --script + mvn 构建是真正值得投资的 10 分钟；）
Eran，不确定您出了什么问题，但我们确实在 roobuild.springsource.org 运行持续 CI，以完成样本的集成测试，包括启动 Web 服务器以确保生成的应用程序正常工作等。跨度>
如果不是使用“同类最佳”一词，这个答案会很棒 - 我讨厌流行语！
Roo 样本永远不会起作用，首页入门者的东西是垃圾。如果在 web gwt 设置之后你执行 web gwt all --proxyPackage com.foo.client.request --requestPackage com.foo.client.request 那么它将适用于 GWT，但不适用于 Tomcat :)

【解决方案5】：

Grails 和 Roo 非常不同。第一个主要区别是使用的语言。虽然您可以像编写传统 Java 代码一样编写 Groovy 代码，但您仍然需要 Groovy 依赖项来运行 Grails 应用程序。为了在 Grails 中尽可能高效，您还需要掌握 Groovy 中当前不属于 Java 的特性，例如闭包。另一个区别是框架生成代码的理念。 Grails 在运行时生成很多方法，而 Roo 在开发过程中根据请求生成它们。 Roo 对面向方面编程的使用没有幕后魔术接受，您可以查看 Roo 生成的所有代码。例如，在 Roo 中，您必须使用命令让它生成动态查找器方法，例如 findByBook()，然后在 .aj 文件中查看生成的代码。在 Grails 中，findByBook() 方法是在运行时创建的，您无法查看生成的代码。如果您选择通过将所有生成的代码合并到正常的 .java 文件中继续运行应用程序，Roo 还允许您停止使用该框架。然后，您在运行时或设计时都不会依赖任何 Roo 库。如果您决定不喜欢 Grails，则无法在继续拥有正常运行的应用程序的同时停止使用该框架。

【讨论】：

【解决方案6】：

它们实际上并不那么相似。 Roo 在编译时执行它的魔法，而 Grails 在运行时执行它。因此，Roo 项目在运行时不会对性能造成任何影响。

我看不出它们如何合并，因为 Grails 是基于 Groovy 和 Java 上的 Roo 构建的。

【讨论】：

【解决方案7】：

IMO 两者不是很相似。尽管有相似之处，但以下是显着差异：

Roo 使用“Stock-Standard Java”， Grails 基于 Groovy
Grails 是一个 Web 框架，Roo 不是

Roo 与 Grails 的命令行系统非常相似（例如 Grails 中的 create-app、create-domain-class、test-app 类型的命令）。看到 Grails 框架的这一部分与 Roo 之间存在某种“异花授粉”，我不会感到惊讶。

【讨论】：

【解决方案8】：

来自 SpringSource 的 Ben Alex 在 this interview 中谈到 Roo，他被问及 Grails 与 Roo 的关系。除了使用不同的语言（如其他人提到的 Groovy 与 Java）之外，主要区别在于 Roo 主要是一个开发时间工具，而 Grails 更多地涉及运行时。

【讨论】：