服务应该总是返回DTO，还是可以返回域模型？

我正在（重新）设计大型应用程序，我们使用基于DDD的多层体系结构。

我们的MVC具有数据层（存储库的实现），域层（域模型和接口的定义-存储库，服务，工作单元），服务层（服务的实现）。到目前为止，我们在所有层上都使用域模型（主要是实体），并且仅将DTO用作视图模型（在控制器中，服务返回域模型，并且控制器创建视图模型，该模型传递给视图）。

我读了无数关于使用，不使用，映射和传递DTO的文章。我知道没有明确的答案，但是我不确定是否可以将域模型从服务返回到控制器。如果我返回域模型，它仍然永远不会传递给视图，因为控制器始终会创建特定于视图的视图模型-在这种情况下，它似乎合法。另一方面，当域模型离开业务层（服务层）时，感觉不对。有时服务需要返回域中未定义的数据对象，然后我们必须向未映射的域中添加新对象，或者创建POCO对象（这很丑陋，因为某些服务返回域模型，因此某些服务有效地返回DTO）。

问题是-如果我们严格使用视图模型，是否可以将域模型一直返回给控制器，还是应该始终使用DTO与服务层进行通信？如果是这样，可以根据需要的服务来调整域模型吗？（坦率地说，我不这么认为，因为服务应该使用哪个域。）如果我们严格遵守DTO，是否应该在服务层中定义它们？（我是这样认为的。）有时候，很明显我们应该使用DTO（例如，当服务执行大量业务逻辑并创建新对象时），有时很显然，我们应该仅使用域模型（例如，当Membership服务返回贫乏的User（ s）-创建与域模型相同的DTO似乎没有多大意义）-但我更喜欢一致性和良好做法。

Article Domain与DTO与ViewModel-如何以及何时使用它们？（以及其他一些文章）与我的问题非常相似，但是并不能回答这个问题。第二条我应该实现与EF存储库模式的DTO？也很相似，但不涉及DDD。

免责声明：我不打算仅仅因为它存在并且很花哨就使用任何设计模式，另一方面，我也想使用好的设计模式和实践，因为它有助于整体上设计应用程序，有助于分离的担忧，至少在目前，甚至不需要使用特定的模式。

与往常一样，谢谢。

域模型离开业务层（服务层）时感觉不对

让您感觉自己在抽胆，对吗？根据Martin Fowler的说法：服务层定义了应用程序的边界，它封装了域。换句话说，它保护域。

有时服务需要返回域中未定义的数据对象

您能否提供此数据对象的示例？

如果我们严格遵守DTO，是否应该在服务层中定义它们？

是的，因为响应是服务层的一部分。如果定义为“其他地方”，则服务层需要引用该“其他地方”，为您的烤宽面条添加一个新层。

是否可以将域模型一直返回给控制器，还是应该始终使用DTO与服务层进行通信？

DTO是响应/请求对象，如果您将其用于通信则很有意义。如果在表示层（MVC-Controllers / View，WebForms，ConsoleApp）中使用域模型，则表示层与您的域紧密耦合，该域中的任何更改都需要您更改控制器。

似乎创建与域模型相同的DTO似乎没有多大意义）

这是DTO的缺点之一。现在，你在想代码的重复，但是随着项目的扩展，它将变得更加有意义，尤其是在将不同团队分配到不同层的团队环境中。

DTO可能会增加应用程序的复杂性，但是您的图层也会增加。DTO是系统的昂贵功能，它们并非免费提供。

为什么要使用DTO

本文提供了使用DTO的优点和缺点， http

总结如下：

何时使用

• 对于大型项目。
• 项目寿命为10年以上。
• 战略性，关键任务应用。
• 大型团队（超过5个）
• 开发人员按地理位置分布。
• 域和表示形式是不同的。
• 减少开销数据交换（DTO的初衷）

何时不使用

• 中小型专案（最多5名成员）
• 项目寿命为2年左右。
• 没有用于GUI，后端等的单独团队。

反对DTO的争论

• 代码重复。
• 开发时间花费，调试。（使用DTO生成工具http://entitiestodtos.codeplex.com/）
• 您必须始终同步两个模型。
• 开发成本：需要附加映射。（使用自动映射器，例如https://github.com/AutoMapper/AutoMapper）
• 为什么数据传输对象是反模式？

与DTO的争论

• 没有DTO，表示和域是紧密耦合的。（对于小型项目，这是可以的。）
• 接口/ API稳定性
• 通过返回仅包含绝对必需的那些属性的DTO，可以为表示层提供优化。使用linq-projection，您不必拉整个实体。
• 为了降低开发成本，请使用代码生成工具

决定采用DDD方法时，您的应用程序似乎足够大且复杂。不要在服务层中返回poco实体或所谓的域实体和值对象。如果要执行此操作，请删除服务层，因为您不再需要它！视图模型或数据传输对象应位于服务层中，因为它们应映射到域模型成员，反之亦然。那么，为什么需要DTO？在具有许多场景的复杂应用程序中，您应该将域的关注点和演示视图分开，一个域模型可以分为多个DTO，并且多个Domain模型也可以折叠为一个DTO。因此，最好在分层体系结构中创建DTO，即使它与您的模型相同。

我们是否应该始终使用DTO与服务层进行通信？ 是的，您必须通过服务层返回DTO，因为您已经与服务层中的域模型成员进行了交谈，并将它们映射到DTO并返回到MVC控制器，反之亦然。

是否可以根据服务需求调整域模型？ 服务只是与存储库和域方法以及域服务进行对话，您应该根据自己的需求解决域中的业务，而不是告诉域所需的服务任务。

如果我们严格遵守DTO，是否应该在服务层中定义它们？是的，请稍后再尝试使用DTO或ViewModel，因为它们应该映射到服务层中的域成员，并且将DTO放置在应用程序的控制器中不是一个好主意（尝试在服务层中使用请求响应模式），欢呼！

以我的经验，您应该做一些实际的事情。“最好的设计是最简单的设计”-爱因斯坦。有了这个...

如果我们严格使用视图模型，是否可以将域模型一直返回给控制器，还是应该始终使用DTO与服务层进行通信？

绝对可以！如果您具有域实体，DTO和视图模型，然后包括数据库表，则应用程序中的所有字段都在4个地方重复。我从事过大型项目，其中领域实体和视图模型工作得很好。唯一的认识是，如果应用程序是分布式的，并且服务层位于另一台服务器上，在这种情况下，出于串行化的原因，DTO需要通过电线发送。

如果是这样，可以根据需要的服务来调整域模型吗？（坦率地说，我不这么认为，因为服务应该消耗域拥有的东西。）

通常，我会同意并说不，因为域模型通常是业务逻辑的反映，并且通常不会受到该逻辑的使用者的影响。

如果我们严格遵守DTO，是否应该在服务层中定义它们？（我认同。）

如果您决定使用它们，我会同意并说“是”，因为服务层将在一天结束时返回DTO，因此是理想的选择。

祝好运！

我参加这个聚会很晚，但这是一个普通而重要的问题，我不得不回答。

“服务”是指埃文在蓝皮书中描述的“应用层” 吗？我会认为你这样做，在这种情况下，答案是，他们应该不返回的DTO。我建议阅读蓝皮书的第4章，标题为“隔离域”。

在该章中，Evans对图层进行了以下说明：

将复杂的程序划分为层。在具有凝聚力的每一层中开发设计，该设计仅取决于下面的层。

这有充分的理由。如果您使用部分顺序衡量软件复杂性，那么依赖于其上一层的层会增加复杂性，从而降低可维护性。

将其应用于您的问题，DTO实际上是用户界面/表示层所关心的适配器。请记住，远程/跨进程通信正是DTO的目的。（值得注意的是，在Fowler的文章中，他也反对DTO是服务层的一部分，尽管他不一定使用DDD语言）。

如果您的应用程序层依赖于这些DTO，则它依赖于自身之上的一层，并且您的复杂性会增加。我可以保证，这将增加维护软件的难度。

例如，如果您的系统与其他几个系统或客户端类型接口，每个系统或客户端类型都需要自己的DTO，该怎么办？您如何知道应返回应用程序服务的哪个DTO方法？如果您选择的语言不允许基于返回类型的方法（在这种情况下为服务方法）重载，您甚至将如何解决该问题？即使您找到一种方法，为什么还要违反您的应用程序层来支持表示层问题？

实际上，这是一条通向意大利面条式建筑的道路。我亲身经历了这种转移及其结果。

我目前工作的地方，应用程序层中的服务返回域对象。我们不认为这是一个问题，因为Interface（即UI / Presentation）层取决于它下面的Domain层。同样，此依赖关系被最小化为“仅引用”类型的依赖关系，因为：

a）接口层只能访问这些域对象，作为通过调用应用层获得的只读返回值

b）应用层中服务上的方法仅接受在该层中定义的“原始”输入（数据值）或对象参数（在必要时减少参数数量）作为输入。具体来说，应用程序服务从不接受Domain对象作为输入。

接口层使用在接口层本身中定义的映射技术将域对象映射到DTO。同样，这使DTO专注于由接口层控制的适配器。

晚了聚会，但是我正面临着完全相同的架构类型，我倾向于“仅来自服务的DTO”。这主要是因为我决定仅使用域对象/聚合来维护对象内的有效性，因此仅在更新，创建或删除时才使用。查询数据时，我们仅将EF用作存储库，并将结果映射到DTO。这使我们可以自由地优化读取查询，而不必使其适应业务对象，经常使用数据库函数，因为它们的速度很快。

每种服务方法都定义了自己的合同，因此随着时间的推移更容易维护。我希望。

到目前为止，我们在所有层上都使用域模型（主要是实体），并且仅将DTO用作视图模型（在控制器中，服务返回域模型，并且控制器创建视图模型，该模型传递给视图）。

由于域模型为整个应用程序提供术语（通用语言），因此最好广泛使用域模型。

使用ViewModels / DTO的唯一原因是在您的应用程序中实现了MVC模式的实现，以将View（任何类型的表示层）和Model（域模型）分开。在这种情况下，您的演示文稿和领域模型是松散耦合的。

有时服务需要返回域中未定义的数据对象，然后我们必须向未映射的域中添加新对象，或者创建POCO对象（这很丑陋，因为某些服务返回域模型，因此某些服务有效地返回DTO）。

我假设您谈论的是应用程序/业务/域逻辑服务。

我建议您尽可能返回域实体。如果需要返回其他信息，则可以返回包含多个域实体的DTO。

有时，使用第三部分框架（会在域实体上生成代理）的人会遇到从服务中暴露域实体的困难，但这只是错误使用的问题。

问题是-如果我们严格使用视图模型，是否可以将域模型一直返回给控制器，还是应该始终使用DTO与服务层进行通信？

我想说在99,9％的情况下返回域实体就足够了。

为了简化DTO的创建并将您的域实体映射到它们，您可以使用AutoMapper。

如果您返回了域模型的一部分，则它将成为合同的一部分。合同很难更改，因为上下文之外的事情取决于合同。因此，您将难以更改域模型的一部分。

域模型的一个非常重要的方面是它很容易更改。这使我们能够灵活地适应域的不断变化的要求。

我建议分析以下两个问题：

1. 您的上层（即视图和视图模型/控制器）是否以域层公开的不同方式使用数据？如果要完成很多映射甚至涉及逻辑，我建议您重新设计：它可能更接近于实际使用数据的方式。

2. 您深刻改变上层的可能性有多大？（例如，将ASP.NET交换为WPF）。如果这很不相同，并且您的体系结构不是很复杂，则最好公开尽可能多的域实体。

恐怕这是一个广泛的话题，它实际上取决于您的系统及其要求的复杂程度。

以我的经验，除非您使用的是OO UI模式（例如裸对象），否则将域对象暴露给UI是一个坏主意。这是因为随着应用程序的增长，UI的需求会发生变化，并迫使您的对象适应这些变化。您最终将获得2个主服务器：UI和DOMAIN，这是非常痛苦的体验。相信我，你不想在那里。UI模型具有与用户进行通信的功能，DOMAIN模型具有保持业务规则的功能，而持久性模型则具有有效存储数据的功能。它们都满足应用程序的不同需求。我正在撰写有关此内容的博客文章，请在完成后添加它。