CRUD：给 Roo 还是不给 Roo？ [关闭]

Posted 2023-02-16

【中文标题】CRUD：给 Roo 还是不给 Roo？ [关闭]

【英文标题】：CRUD: To Roo or not to Roo? [closed]

【发布时间】：2011-05-13 17:00:23

【问题描述】：

我一直在将 Groovy on Rails 用于 CRUD 应用程序。我正在开始一个新项目，我们不再允许使用 Grails（我们有一个允许的 jars 和 grails 列表 不在这里）。

我正在考虑使用 Spring ROO 或 JBoss Seam。他们如何比较？他们的主要优势和劣势是什么？

【问题讨论】：

我也会对此感兴趣。很惊讶还没有人回答……也许一点激励措施会有所帮助。 :)

请don't add signatures回答您的问题/答案。

如果它确实对您有所帮助，请不要忘记接受答案。

【参考方案1】：

请注意，Spring Roo 和 JBoss Seam 不能直接比较，因为 JBoss Seam 本身不提供问题中提到的 CRUD 应用程序生成。然而，JBoss Seam 带有提供此功能的 seam-gen 工具。因此，最好将 JBoss Seam 与 Spring 框架相比较，并将 seam-gen 工具与 Spring Roo 进行比较。我知道这也不是一个完整的比较，但我猜这超出了这个话题。需要说明的是，在下面的答案中，当我提到JBoss Seam时，我实际上是指结合seam-gen工具的JBoss Seam。

Spring Roo 和 JBoss Seam（使用 seam-gen）都使创建 CRUD 应用程序变得非常容易，顺便说一下，Play Framework 和 RIFE 等其他 Java 全栈/脚手架解决方案也是如此。如果您比较这两者（Spring ROO 和 JBoss Seam 与 seam-gen），基于现有数据库或通过添加实体并定义字段和关系来启动和运行新的基本 CRUD 应用程序的速度，我猜有差别不大。根据我的经验，您可以在 Spring Roo 中（稍微）快一点，但是您可以在不到一个小时（如果是现有数据库的情况下）或不到（半）天（在如果您必须手动添加所有实体和关系）。

在继续之前，读者应该注意，整个比较是基于我对这两种解决方案的卑微经验进行的，因此基于 Spring Roo 版本 1.1.0 和 JBoss Seam 1.2 和 2.x。读者还应该注意，目前已经有一个出色的 Seam 3 版本（实际上是带有 Seam 模块插件的 CDI（焊接）），它基于 Java EE 6 规范，但是这个新版本的 JBoss Seam 不再具有接缝- gen 应用程序，因此还没有使用 Spring Roo 和 JBoss Seam 2.x 及更低版本等几个命令创建完整 CRUD 应用程序的功能。不过，目前 JBoss 的一些人正在从事类似的工作，名为 JBoss Forge，看起来很有希望，但截至今天，还没有任何实际发布，因此我猜还不是一个选项。

Spring ROO 和 JBoss Seam（使用 seam-gen）都创建了一个不错的基本 CRUD 应用程序，尽管 Spring Roo 生成的应用程序的默认 UI 设计在我看来要好一些，但您可能想要重新设计它无论如何，这对任何一个都没有太大的争议。创建的 Web 应用程序在提供的功能上也略有不同，但就基本的 CRUD 功能和其他基本功能（如身份验证和国际化）而言，它们彼此相提并论。

我认为主要区别以及决定选择哪个应用程序的原因不在于生成基本 CRUD 应用程序所需的时间，也不是在脚手架式基本 CRUD 应用程序中，而是在更重要的事情上，例如架构/设计决策、使用、支持、文档、灵活性、可维护性、扩展点等。就我而言，Spring Roo 和 JBoss Seam 都是基于您的 Web 应用程序的绝佳选择（事实上，我的团队已经使用两者创建了生产应用程序），但在您做出决定之前，您必须查看这些重要差异并确定最适合您的方法。当然，最好的决定方法是用这两种选择为自己做一个概念验证，但如果你没有时间和/或资源，这就是我能想到的（从顶部我的头脑）这是两者之间的差异，这可能会帮助您决定哪种方式：

Spring Roo 中使用的底层构建系统是 Maven，其中 JBoss Seam 使用 Ant。据我所知，Seam 也可以与 maven 一起使用，但 seam-gen 默认使用 Apache Ant。请注意，JBoss Forge（seam-gen 的替代品，实际上更像 Spring Roo）正在使用 Maven。 Spring Roo 基于 Spring 框架，而 JBoss Seam 基于整个 Java EE 5 堆栈（Seam 3 将使用 Java EE 6 堆栈）。请注意，JBoss Seam 和 seam-gen 工具默认使用 EJB 3.0，但这是可选的，您也可以选择使用 JBoss Seam 和 seam-gen 工具的非 EJB 解决方案。 JBoss Seam（使用 seam-gen）使用基本的 OO 继承，通过扩展 JBoss Seam 特定的类来为生成的类添加基本功能。这确实为 JBoss Seam（和 seam-gen）特定类添加了运行时依赖项。 Spring Roo 选择了一种完全不同的方法，通过生成纯 Java 源文件（不扩展 Spring 相关类）和注释这些类。除了生成的 Java 源文件之外，Spring Roo 还生成一到几个所谓的类型间声明 (ITD) 文件，它们是包含生成的源代码和注释的 AspectJ 特定文件。这些 ITD 文件将在编译时完全透明地编织到生成的类文件中，因此不会强加运行时依赖性。 Seam 生成的文件可以（并且将会）由您更新，但是如果您需要使用 seam-gen 重新生成文件，它将覆盖您的手动更改，这是因为您将在 Seam-gen 生成的文件中进行更改文件。由于 Spring Roo 使用 ITD 的方法，您在 Java 源文件中进行更改以覆盖 ITD 文件中生成的源代码。这使得 Spring Roo 可以在保留 Java 源文件中的手动更改时重新生成 ITD，然后保持不变。 seam-gen 的使用更倾向于一次性生成/使用来初始设置项目并开始运行，而 Spring Roo 则在项目的整个生命周期中使用。 可以从项目中删除 Spring Roo，留下一个完全正常工作的项目，该项目不再依赖于 Spring Roo，当然仍然可以按照您想要的任何方式构建和扩展。 seam-gen 实用程序不提供这样的功能，但在 seam-gen 的情况下，您当然永远不会依赖 seam-gen 本身，而是依赖于特定的 JBoss Seam 包（称为框架）。 JBoss Seam（带有 seam-gen）主要针对使用 JSF 作为 Web 框架，而 Spring Roo 专注于 Spring MVC 和/或 GWT 作为其 Web 框架。 JBoss Seam 本身对 Wickete 也有很好的支持，但不支持 seam-gen 工具。 Spring Roo 也有一个 Flex 插件，社区中创建了更多用于其他 Web 框架的插件，但它们仍然不如 Spring MVC 和 GWT 的插件。 文档非常适合 JBoss Seam 和 Spring，但对于 Spring Roo 和 seam-gen 工具，它们缺乏更高级的文档。顺便说一下，Spring Roo 还在命令行 shell 中提供了非常有用的提示。 IDE 对 JBoss Seam 方法的支持优于 Spring Roo 方法。这两种解决方案都有一个基于 Eclipse 的特定 IDE 和插件（用于 Spring Roo 的 SpringSource Tool Suite 和用于 JBoss Seam 的 JBoss IDE）和所有其他大型 IDE（Netbeans en IntelliJ）对基本框架都有很好的支持，但非 Eclipse IDE（虽然不完全确定 IntelliJ IDE）对 Spring Roo 生成的 ITD 没有很好的支持。这在构建中不是问题，但确实会在这些 IDE 中提供与智能感知和代码完成相关功能的问题。

虽然这两个伟大的产品之间当然有更多的区别，而且我什至还没有触及重要的事情，比如可测试性、学习曲线和这些项目的未来，但我希望上面的要点可能已经对正在考虑这些的人有所帮助两种解决方案，以做出至少更有根据的决定。我想再次强调，做出决定的最佳方法仍然是使用这两种方法创建概念验证，然后看看哪种方法最适合您。

以我的拙见，可能会让您做出简单快速决定的要点是在 Spring 堆栈或 Java EE 堆栈、IDE 支持、Web 框架和解决方案的“成熟”之间进行选择。因此，如果您对 Spring 堆栈非常熟悉（我猜您是，因为您来自 Grails），请选择 Spring Roo，否则您可能会浪费一些时间来熟悉 Java EE 堆栈，包括 JSF （当然这取决于你项目的规模，但假设它不是一个非常大的项目，学习新技术的影响对于单个项目来说可能太大了）。如果您不能或不想使用 Eclipse 并且对此充满热情，我想 JBoss Seam 可能是一个更好的解决方案。如果您想使用 JSF 或 Wicket，请选择 JBoss Seam，而如果您想使用 Spring MVC 或 GWT，请使用 Spring Roo（对于其他 Web 框架，您选择哪个可能并不重要，尽管 Spring roo 可能是更好的解决方案）。如果“成年”是您的主要决定点，我想您最好使用 JBoss Seam。总而言之，在两者之间做出决定可能非常困难，但至少要知道这两种解决方案都非常棒，并且无论哪种方式都会对您有很大帮助。

顺便说一句，请务必留意 JBoss Forge 项目，因为当前的 seam-gen 解决方案将在不久的将来被这个有前途的项目所取代。

【讨论】：

谢谢。一个非常详细和公正的答案。作为一名在 VMWare 从事 AspectJ 和 Groovy 工具支持工作的开发人员，我希望更多地比较 Spring Roo 和 Grails。但是，既然您提到了它，您能否更详细地谈谈您在 STS 中发现的 Spring Roo 工具支持的缺点？

谢谢安德鲁。由于我最近没有使用 Grails，因此在上述答案中我没有考虑这种方法。不过我有兴趣在某一天将 Grails 与 Spring Roo 和 Seam 进行比较，所以也许我会添加新的评论或答案。

关于 IDE 支持，我认为 STS 在对 Spring Roo 的支持方面并没有太多不足（如果有的话）。在我看来，对 Spring Roo 的 IDE 支持略低于对 JBoss Seam 的原因是其他主要 IDE，例如 NetBeans，对 AspectJ 没有很好的支持，因此 Roo 生成的 ITD 存在问题，导致自动完成/智能感知问题。所以支持的区别不在于功能，而在于不同的 IDE。

【参考方案2】：

只是伪造它 -> http://forge.jboss.org

如果您是新手，您将拥有一个具有持久性、测试和安全性的 Web 应用程序。还有更多。

如果您了解 Java，您将拥有与上述相同的知识以及如何制作出色应用程序的惊人知识来源：Forge 生成的源代码和资源。你可以学到很多关于 Java EE（CDI、Validation、JSF）、maven、JPA、tiles、EJB...等等。

【参考方案3】：

就这样吧。

如果您是新手，您将拥有一个具有持久性、测试和安全性的 Web 应用程序。还有更多。

如果您了解 Java，您将拥有与上述相同的知识以及如何制作出色应用程序的惊人知识来源：Roo 生成的源代码和资源。您可以学到很多关于 Spring（核心、安全、MVC）、maven、JPA、tile、messagign 的知识……等等。