Grails VS Roo ——为什么 SpringSource 推出了两种非常相似的技术?

SpringSource (现在的 VMWare)有两种非常相似的技术: Grails 和 SpringRoo。我一直在使用 Grails,但是我看到 SpringSource 正在积极地开发一些东西,这些东西是 Grails 技术的竞争对手,这让我对 Grails 的未来感到担忧。

有人知道这些技术是如何联系在一起的吗? 它们是会被合并,还是会被放弃?

此外,Grails 和 Roo 之间有什么重要的技术差异吗?

28361 次浏览

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

这个问题是在 Roo 发布时提出的,Graeme Rocher (Grails 的领导者)说这两个框架在 Spring 中都有一席之地,并且受到同等的支持。

如果说有什么区别的话,那就是我认为 Grails 的前景比 Roo 更光明。我喜欢使用它进行开发,并且不认为它不是纯 Java 有任何缺点。

我认为,这两者并不十分相似,尽管有相似之处,但仍有显著差异:

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

Roo 非常类似于 Grails 的命令行系统(例如,Grails 中的 create-appcreate-domain-classtest-app类型命令)。如果在 Grails 框架的这一部分和 Roo 之间看到一些“交叉授粉”,我不会感到惊讶。

来自 SpringSource 的 Ben Alex 在 这次采访中谈到了 Roo,他被问到了 Grails vs Roo。除了使用不同的语言(Groovy VS Java,正如其他人提到的)之外,Roo 主要是一个开发时工具,Grails 更多地涉及到运行时。

其实没那么相似。Roo 在编译时起到了神奇的作用,而 Grails 在运行时起到了神奇的作用。因此,Roo 项目在运行时不会受到任何性能影响。

由于 Grails 是基于 Java 上的 Groovy 和 Roo 构建的,我无法看到它们如何合并。

圣杯和小袋鼠非常不同。第一个主要区别是所使用的语言。虽然可以像传统 Java 代码那样编写 Groovy 代码,但是仍然需要 Groovy 依赖项来运行 Grails 应用程序。为了在 Grails 中获得尽可能高的效率,您还需要掌握 Groovy 中目前不属于 Java 的特性,比如闭包。另一个区别是框架生成代码的理念。Grails 在运行时生成许多方法,而 Roo 在开发过程中根据请求生成这些方法。Roo 没有为面向方面编程的使用提供幕后魔法接受,您可以查看 Roo 生成的所有代码。例如,在 Roo 中,必须使用命令使其生成动态查找器方法,如 findByBook () ,然后在。AJ 档案。在 Grails 中,findByBook ()方法是在运行时创建的,您无法查看生成的代码。Roo 还允许您停止使用框架,如果您选择继续运行应用程序的话,可以将所有生成的代码合并为普通代码。Java 文件。然后,您在运行时或设计时就不再依赖于任何 Roo 库。如果您决定不喜欢 Grails,那么就没有办法在继续使用一个正常运行的应用程序的同时停止使用该框架。

SpringSource 的目标是让人们尽可能快速、方便地构建、运行和管理基于 Spring 的解决方案。我们同时拥有 圣杯春袋鼠,因为我们非常关心开发人员的生产力,而且毫无疑问,这两个工具都对团队在 Spring 之上可以实现的目标起到了很大的推动作用。

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

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

我们最好的建议是同时考虑这两种解决方案。每种技术都有各自的优点,但是两者之间存在差异,在给定的环境中,使用这种技术或另一种技术将使您的整体体验更好。两个参考指南详细说明了 每个解决方案各自的利益。当然,请记住,尝试这两种方法所花费的时间是最少的。在10分钟内,你可以在 Roo 或 Grails 中构建一个项目,所以尝试一下,看看在你的特定背景和项目需求下,什么对你来说更自然。

我在 Grails 邮件列表中看到了一些评论,这些评论表明作者认为 Roo 只是 Grails 的垫脚石!然而,我个人正在考虑从 Grails 转换到 Roo 的可能性。我认为主要的区别在于动态语言和静态类型语言之间——对我来说这是巨大的差异。我喜欢 Grails 的许多特性,但我更喜欢 IDE 支持和静态类型语言的编译时检查。其他一些人的感觉正好相反,因此马匹的课程。也就是说,静态 Groovy 目前正在大力开发之中,所以谁知道未来会发生什么。

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

如果您想查看分析的详细信息,请访问@http://krishnasblog.com/2012/05/08/roo-vs-grails/

我们探讨了以下这些特点和以下是我们的发现。如果我们不确定是否会使用这两种誓不低头(无线电视剧) ,我们仍在探索