oop – DDD:放置持久逻辑的位置,何时使用ORM映射

前端之家收集整理的这篇文章主要介绍了oop – DDD:放置持久逻辑的位置,何时使用ORM映射前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我们正在对 Java( Java)Web应用程序模式进行漫长而艰苦的考察.过去,我们遭受过度贫乏的对象模型和控制器,服务和DAO之间的过度程序分离,简单的价值对象(基本上只是数据包)在它们之间传播.我们已经使用声明式(XML)管理的ORM(Hibernate)来保持持久性.所有实体管理都在DAO中进行.

在尝试转向更丰富的域模型时,我们发现自己在如何最好地设计持久性层面上挣扎着.我花了很多时间阅读并思考域驱动设计模式.但是,我想要一些建议.

首先,我更有信心的事情:

>我们将在前端有“薄”控制器,只处理HTTP和HTML处理表单,验证,UI逻辑.
>我们将有一层无状态的业务逻辑服务,实现常见的算法或逻辑,不知道UI,但非常了解(和委派)域模型.
>我们将拥有一个更丰富的域模型,其中包含该域模型中的对象所固有的状态,关系和逻辑.

问题在于持续性.以前,我们的服务将通过DAO注入(通过Spring),并且将使用像find()和save()这样的DAO方法来执行持久性.然而,更丰富的域模型似乎意味着对象应该知道如何保存和删除自己,也许更高级别的服务应该知道如何定位(查询)域对象.

这里有几个问题和不确定因素出现:

>我们要将DAO注入域对象,以便它们可以在save()方法中执行“this.someDao.save(this)”?这是一个有点尴尬,因为领域的对象不是单身,所以我们需要工厂或建设后的DAO设置.从数据库加载实体时,这会变得凌乱.我知道Spring AOP可以用于此,但我无法使其工作(使用Play!框架,另一行实验),它似乎相当凌乱和神奇.
>我们是否将DAO(存储库?)完全分开,与无状态业务逻辑服务相同?这可以有所意义,但这意味着如果“保存”或“删除”是域对象的固有操作,则域对象不能表达.
>我们是否完全免除DAO,并使用JPA让实体管理自己.

这就是下一个微妙之处:使用JPA映射实体是非常方便的.表演!框架为我们提供了一个很好的实体基类,其操作类似于save()和delete().然而,这意味着我们的域模型实体与数据库结构非常紧密相连,我们正在使用大量的持久性逻辑传递对象,也许一直到视图层.如果没有别的,这将使得域模型在其他上下文中不太可用.

如果我们想避免这种情况,那么我们需要一些映射DAO – 使用简单的JDBC(或至少Spring的JdbcTemplate),或者使用数据库实体和“业务”实体的并行层次结构,DAO永远复制信息一层到另一层.

这里有什么适当的设计选择?

马丁

你的问题和疑惑在这里引起了一个有趣的警报,我想你对“丰富的领域模式”的解释已经有点太远了. Richness不会暗示持久性逻辑必须由域对象处理,换句话说,不,他们不应该知道如何保存和删除自己(至少不是明确的,尽管Hibernate实际上添加了一些持久性逻辑透明).这通常被称为持久性无知.

我建议您保留现有的DAO注入系统(对于单元测试来说是一件好事),并保留持久层,同时尝试将一些业务逻辑移动到您的实体.这样做的一个好的起点是识别聚合并建立您的聚合根.他们经常会包含比其他实体更多的业务逻辑.

然而,这并不是说域对象应该包含所有的逻辑(尤其是应用程序中许多其他对象所需的逻辑,这通常属于服务).

原文链接:https://www.f2er.com/javaschema/281792.html

猜你在找的设计模式相关文章