.net - 在大型 .NET 项目中管理 DTO 和映射

Question

我和我的团队正在构建一个大型的 .NET WinForms 应用程序。该应用程序使用各种“服务”从我们的数据库中获取数据。每个“服务”都存在于自己的解决方案中，并处理特定类型的数据。因此，例如，我们的“ContactsService”管理检索/保存联系人到我们的数据库。

通常，我们一直在为每个服务构建 DTO。因此，我们可能有一个“ContactDTO”，它为联系人上的每条数据提供简单的字符串属性。现在，我们还有一个具有完全相同属性的业务层“Contact”类，也许还有一些具有某些业务逻辑的额外方法。最重要的是，“ContactsService”有自己的 Contact 类，它是从 ContactDTO 中提取的。

管理我们所有的 DTO 和映射已经成为一个巨大的痛苦。目前，发送要存储在数据库中的联系人如下所示:

将客户联系人映射到联系人DTO

映射联系DTO到服务联系方式

保存联系方式

map 服务 联系方式DTO

将 ContactDTO 映射到客户联系人

这只是感觉很糟糕。如果我们向客户端 Contact 类添加属性，则必须在 3-4 个位置添加属性和映射。

我们做错了什么，如何让我们的生活更轻松？使用像 Json.NET 这样的东西并拥有 JSON DTO 会更简单吗？我们检查了 AutoMapper，但一些团队成员认为它太复杂了。

Answer 1

我遇到过很多这种情况，但就我而言，我选择接受它，因为使用 DTO 的决定是有意为之——我希望我的服务、客户端、代理和契约(Contract)程序集完全分开。

使用 WCF 时，我更喜欢的布局是这样的(使用您的联系人示例):

客户端组装

联系方式(具有客户特征)

共享合约程序集

联系方式(约定的通用DTO)

代理程序集

使用来自共享契约(Contract)程序集的联系人

服务组装

联系人(具有 service-y 业务逻辑特征，例如这可能是像 Entity Framework 这样的 ORM 层公开的类型)

我现在正在共享服务和客户之间的契约(Contract)。如果我需要独立地对它们进行版本控制，那么我只需复制共享的 Contracts 程序集并重新定位 Proxy 程序集以使用该副本，然后独立修改两个 Contracts 程序集。但在我工作过的大多数情况下，我同时拥有客户端和服务，因此在两者之间共享 Contracts 程序集很方便。

这是我在做出架构决策以使用 DTO 隔离组件时我能想到的唯一优化，至少在不使用代码生成工具的情况下(我不知道有什么好的，但不必研究它们) .

编辑:当不使用 WCF 时，您显然不需要“代理”程序集。