我有一个 Java\Spring\Hibernate 应用程序 - 包含基本上是 Hibernate POJO 的域类
我认为有一个功能可以在 Grails 中很好地编写。
我希望重用我在主 Java 应用程序中创建的域类
最好的方法是什么？
我应该编写扩展 Java 类的新域类吗？这听起来很俗气 或者我可以从 Java 域类中“生成”控制器吗？
在 Grails\Groovy 中重用 Java 域对象的最佳实践是什么 我相信肯定有其他人在 grails\groovy 中写了一些文章
如果您知道有关此类集成的教程，那就太棒了！！！
PS：我是 grails-groovy 的新手，所以可能会错过明显的内容。谢谢！！！
【问题讨论】：
知道 Groovy 和 Grails 在与现有 Java 代码集成方面的出色表现，我想我可能比 Michael 对您的选择更加乐观。
首先，您已经在使用 Spring 和 Hibernate，并且由于您的域类已经是 POJO，它们应该很容易集成。您可能拥有的任何 Spring bean 都可以像往常一样在 XML 文件中指定（在 grails-app/conf/spring/resources.xml 中），或者更简单地使用 Grails 的 Spring bean builder 特性。然后可以在任何控制器、视图、服务等中按名称访问它们并像往常一样使用它们。
在我看来，以下是集成域类和数据库架构的选项：
绕过 GORM 并完全按照您的方式加载/保存您的域对象。
Grails 不会强制您使用 GORM，因此这应该非常简单：创建 Java 代码的 .jar（如果您还没有的话）并将其放入 Grails 应用程序的 lib 目录中。如果您的 Java 项目是 Maven 化的，那就更容易了：Grails 1.1 与 Maven 一起工作，因此您可以为您的 Grails 应用程序创建一个 pom.xml，并像在任何其他 (Java) 项目中一样将您的 Java 项目添加为依赖项。
无论哪种方式，您都可以import您的课程（以及任何支持课程）并照常进行。由于 Groovy 与 Java 的紧密集成，您将能够像在 Java 项目中一样创建对象、从数据库加载它们、修改它们、保存它们、验证它们等等。通过这种方式您不会获得 GORM 的所有便利，但您将拥有以对您来说已经有意义的方式处理对象的优势（除了由于 Groovy 可能使用更少的代码）。您总是可以先尝试此选项以使某些东西发挥作用，然后如果当时看起来有意义，然后再考虑其他选项之一。
如果您确实尝试此选项，一个提示：将实际的持久性代码抽象为 Grails 服务（可能是StorageService）并让您的控制器调用其上的方法，而不是直接处理持久性。这样，如果需要，您可以用其他东西替换该服务，并且只要您保持相同的界面，您的控制器就不会受到影响。
创建新的 Grails 域类作为现有 Java 类的子类。
如果你的类已经写成适当的 bean，这可能非常简单，即所有属性都有 getter/setter 方法。 Grails 将看到这些继承的属性，就好像它们是用更简单的 Groovy 风格编写的一样。您将能够指定如何验证每个属性，使用简单的验证检查（非 null、非空白等）或使用执行更复杂事情的闭包，可能调用其 POJO 超类中的现有方法。
您几乎肯定需要通过GORM mapping DSL 调整映射以适应您现有数据库架构的实际情况。关系可能会变得棘手。例如，您可能有其他一些解决方案，其中 GORM 需要一个连接表，尽管甚至可能有一种方法可以解决诸如此类的差异。我建议你尽可能多地学习 GORM 及其映射 DSL，然后尝试一些你的类，看看这是否是一个可行的选择。
让 Grails 直接使用您现有的 POJO 和 Hibernate 映射。
我自己没有尝试过，但根据 Grails 的Hibernate Integration page，这应该是可能的：“Grails 还允许您用 Java 编写域模型或重新使用已使用映射的现有域模型Hibernate。你所要做的就是将必要的'hibernate.cfg.xml'文件和相应的映射文件放在'%PROJECT_HOME%/grails-app/conf/hibernate'目录中。你仍然可以调用所有的GORM 中允许的动态持久化和查询方法！”
谷歌搜索“gorm legacy”会发现许多有用的讨论和示例，例如 Glen Smith 的this blog post（即将发布的Grails in Action的合著者）他在其中展示了一个用于与“来自地狱的遗留数据库”集成的 Hibernate 映射文件。 Grails in Action 有一章标题为“高级 GORM Kungfu”，承诺对此主题进行详细讨论。我有这本书的预发行 PDF，虽然我还没有读到那一章，但到目前为止我读到的内容非常好，而且这本书涵盖了许多其他 Grails 书籍中没有充分讨论的主题.
抱歉，我无法就最后一个选项提供任何个人经验，但它听起来确实可行（而且很有希望）。无论您选择哪个选项，请告诉我们结果如何！
【讨论】：
您真的想要/需要使用 Grails 而不仅仅是 Groovy？
Grails 确实不是您可以用来将部件添加到现有 Web 应用程序的东西。整个“约定优于配置”方法意味着您几乎必须遵守 Grails 的规则，否则使用它毫无意义。其中一个规则是域对象是被 Grails 运行时大量“增强”的 Groovy 类。
也许可以让它们扩展现有的 Java 类，但我不会打赌——你现有应用程序的所有 Spring 和 Hibernate 部分都必须被丢弃，或者至少你必须花费为使它们在 Grails 中工作付出了很多努力。您将与框架抗争，而不是从中获利。
IMO 你有两个选择：
在您的情况下，后者可能更好。 Grails 旨在非常快速地创建新的 Web 应用程序，这就是它的亮点。向现有应用添加东西并不是它的用途。
编辑： 关于 cmets 中的说明：如果您打算基本上为另一个应用程序使用的数据编写一个数据输入/维护前端，并将数据库作为它们之间唯一的通信通道，那么这实际上可能与 Grails 配合得很好；它当然可以配置为使用现有的 DB 模式，而不是从域类中创建自己的模式（尽管后者的工作量较少）。
【讨论】：
这篇文章为wrapping existing Java classes in a web framework 提供了一些使用grails 的建议。
【讨论】：