如何在Grails中拆分域逻辑和数据访问
如何在Grails中拆分域逻辑和数据访问(这是一个好主意)？
我们编写的许多软件应用程序都是以数据(基)为中心的，在Grails中，经常会从服务类或控制器直接持久化到DataSource.groovy中配置的数据库。更改数据库很容易，但我们并不完全独立于代码中的持久性实现。
我试图编写一个为不同的持久性和数据源(不仅仅是数据库)实现打开的应用程序，并将重点放在业务域而不是数据库实体上。在测试时(容易编写假/模拟持久性)，这也是一个好处--最初我只有一个持久性实现--使用GORM的Grails域类。但是，将来我可能希望拥有数据库以外的其他数据源，例如rest服务或其他什么。
目前，我只将数据库作为数据源，并且主要做crud操作(以及一些域逻辑)。我认为我仍然停留在“旧”思维中，专注于数据库持久性，因为我的大部分业务域类都有一个Grails域类，即它的副本。当要持久化域类时，我只需将属性复制到Grails域类。
我对这个解决办法不太满意。我至少可以想到两种可能的改进/改变：
- 我的Grails域类可以与业务域类更不同的组织方式，所以我不只是将属性从一个类复制到另一个类。不过，在从/写入数据库时，这仍然需要从一个类到另一个类的大量属性映射。
- 也许有一种方法可以使用业务域类，从常规的src/main/groovy包中使用GORM之类的东西来装饰？还是以其他方式分割域逻辑和持久化？我已经看到，通过在域类上使用hibernate conf是可以做到这一点的。这是唯一的办法吗？
我看到了一些关于Grails体系结构的有趣的讨论，包括干净的体系结构、六边形的体系结构和ddd，但是我还没有找到任何例子。有吗？
在这一点上，正如我所说的，大部分功能都是CRUD功能，但不是所有功能。而且，应用程序可能具有更多的业务逻辑，因此我不希望使用带有视图、控制器、服务、域的Grails“默认”体系结构。我需要一个“核心”应用程序，它在某种程度上独立于grails视图/控制器和域/GORM。
回答 1
Stack Overflow用户
发布于 2015-06-14 03:36:02
你写问题已经有一段时间了，但这对我来说是个很有趣的话题.
我目前在大型Java8项目中工作，这些项目实现清洁架构、ddd、cqr和六角形体系结构等原则。我在Grails1.x项目方面的经验也很有限，我记得我问过的问题和你现在一样。
现在我有了更广阔的视角，我真诚地认为，强迫Grails进入一个干净的体系结构是没有意义的。你会有一个非常痛苦的时间，试图实现它，你可能会不满意的结果。
Grails中的所有东西都被设计成以一种固执己见、基于约定的方式使用。从GORM是一个ActiveRecord实现开始，然后是他们就目录结构、您需要定义的工件(控制器、服务、模型.)的语义所做的每一个小小的决定。我不是说这很糟糕。事实上，当您正在开发适合于这种事物模式的东西时，这是很棒的。
工件之间的这种耦合和隐式行为使得除了数据访问(或http交互，或与第三方的任何其他交互)之外，很难建模您的业务逻辑。
从DDD的角度来看，您应该倾向于数据或基于集合的存储库，而不是ActiveRecord实现。然后，您可以开始将持久化逻辑与域模型分离。尝试这样做，同时保持ActiveRecord与持久化层的交互，将会产生一个非常“脏”的适应性层，并且会有大量的重复。
您将遇到一段非常困难的时间，特别是在尝试使用聚合对象来调整复杂域时，例如，这些对象应该进入不同的数据库表。
现在，针对您建议的两个改进，我可以告诉您：
- 我的Grails域类可以与业务域类更不同的组织方式，所以我不只是将属性从一个类复制到另一个类。不过，在从/写入数据库时，这仍然需要从一个类到另一个类的大量属性映射。
你真的可以按你说的做。只需在src/groovy文件夹中放置一些代码即可。这里您将面临的主要问题是依赖注入。Grails在标准目录中定义服务和控制器时自动注入它们的依赖项。对于其他方面，您需要显式地进行告诉Grails如何获取依赖项并将它们传递给您的自定义工件。。
- 也许有一种方法可以使用业务域类，从常规的src/main/groovy包中使用GORM之类的东西来装饰？还是以其他方式分割域逻辑和持久化？我已经看到，通过在域类上使用hibernate conf是可以做到这一点的。这是唯一的办法吗？
如果您用GORM装饰在src/groovy中定义的域对象(如果可能的话)，您将遇到同样的问题。这里的任务是将您的域与持久性逻辑隔离开来。这样做的方式是让任何一个戈姆都没有达到它的目的。
我在这里的建议是：
有一个非常全面的库列表，您可以浏览它以获得灵感：超赞Java
https://stackoverflow.com/questions/27885441
复制
腾讯云开发者
