代码之家 › 专栏 › 技术社区 › Antoine Robin

应用程序服务责任与优化的DTO

aspnetboilerplate domain-driven-design

1

Antoine Robin · 技术社区 · 7 年前

我觉得我的MPA ABP应用程序开发中有三个原则,我认为是DDD原则:

:父实体>实体。

放置GetAllParent()、GetAllEntities(父id)和GetEntity(id) 全部在MyViewApplicationService中 ,则我的应用程序服务可以根据我的视图需要返回优化的DTO,但是 ,
不同的应用程序服务 ,但DTO是面向领域的,有些通用。所以 DTO未优化 .
让控制器负责映射到符合视图需要的DTO,但是 .

2 回复 | 直到 7 年前

1

choquero70 7 年前

应用程序服务不必绑定到控制器。我的意思是,控制器不必总是只使用一个应用程序服务。

应用程序服务与客户机类型无关,而是与客户机需求有关。它们返回客户机需要的数据,因此从这个意义上说,应用程序服务考虑了客户机(表示)。

应用程序服务总是获取并返回DTO。

不总是这样。正如沃恩·弗农(Vaughn Vernon)在其《实现DDD》(第512页)一书中所说,DTO还有其他替代方案:

什么选择尊重更好的DDD?

将GetAllParent()、getAllenties(parentId)和GetEntity(id)全部放在MyViewApplicationService中,然后我的应用程序服务可以返回

您不应该根据客户机技术(MyView)来命名应用程序服务,而应该根据它提供的功能来命名。

面向领域,有点通用。因此,DTO没有得到优化。

无论是将这3种方法放在一个服务中,还是每个方法都有一个服务。控制器无论如何都应该调用它们。

让控制器负责映射到符合视图需要的DTO,但它不应该这样做。

如果您的意思是应用程序服务返回域对象,并且控制器将它们转换为DTO,那么不,您不应该这样做,因为您正在向客户机公开域。

2

0

Robert Bräutigam 7 年前

我理解你的问题,我想,让我们从头开始:

商业人士会理解其中哪一个词?这些词中有没有一个是普遍存在的语言的一部分?

它们当然都是纯技术性的,因此应该是细节,不应该影响架构。基本上,他们会在错误的地方,他们不应该是可见的。

DTO不应该是任何远程面向对象的东西的一部分。但是,您并没有说您想要对象定向,所以我们不要详细讨论它。

但是,如果您的对象应该是面向领域的,那么它为什么不适合(未优化)专门为该领域编写的应用程序呢?

我的意思是,如果您正在显示产品的配置文件,那么您的“对象”应该是 ProductProfile Product . 或 ProductDetails 或 ProductHeroImage 那些事情是需求文档中可能也提到了域和。

让控制器负责映射到符合视图需要的DTO,但它不应该这样做。

为什么不这样做呢?如果功能的目的是向用户显示一些数据,那么为什么不将其视为“业务功能”。我的意思是,事实上应该是相反的。“视图”是您想要的业务功能,而数据库/存储库/控制器/服务或任何“公正”技术应该只是一个细节,在体系结构中不可见。

:我必须承认,这些观点并不是DDD下的大多数项目所做的,但也许你会从中发现一些道理,在未来对这些项目提出更多的质疑。:)