问大型.NET项目中DTO的管理与映射

EN

我经常遇到这种情况，但在我的例子中，我选择接受它，因为使用DTO的决定是有意的--我希望我的服务、客户端、代理和合同程序集被清晰地分开。

在使用WCF时，我喜欢的布局如下(使用您的联系人示例)：

• 客户端程序集
  • 联系人(有客户端-y
  • )

​

DTO)

• 共享合同程序集
  • 联系人(约定的公共
  • )

​

assembly

• 代理程序集
  • 使用来自共享契约
    • 的联系人。

​

Framework)

• 服务组装
  • 联系人(具有服务-y业务逻辑特性)，例如，这可能是实体
  • 之类的ORM层公开的类型。

​

我现在在服务和客户之间分享合同。如果我需要独立地对它们进行版本化，那么我只需创建共享契约程序集的副本，并重新针对代理程序集使用该副本，然后独立地修改两个合同程序集。但是在我工作过的大多数情况下，我同时拥有客户端和服务，所以在两者之间共享合同组装是很方便的。

这是我在做出将组件与DTO隔离的体系结构决策时所能想到的唯一优化，至少不需要使用代码生成工具(我不知道有什么好的工具，但没有必要对它们进行研究)。

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

AutoMapper并不特别复杂。如果您遵循这些约定，例如Contact.Address1成为DTO上的ContactAddress1，那么除了对Mapper.Map的调用之外，您不必编写太多的代码。或者，您可以使用代码生成，但是管理更改仍然很棘手。

我能问你为什么需要同时拥有一个ContactDTO和一个服务联系人吗？你就不能直接把服务联络人传过来吗？我知道这不是最好的实践，但它可能会让你免于RSI。

编辑:忽略我的最后一点--出于某种原因，我认为您是在将服务联系人映射到数据库实体，如NHibernate/Entity

有一些事情需要加快进程来考虑：

我编写了一个代码生成器，您可以从数据库中选择表和列，并让它生成一个C# DTO。这样可以节省大量不必要的输入，并且可以更快地生成DTO。先花点时间，但是当你有一个有20个列的表时，你需要映射，这会有所帮助。

我还编写了代码生成器，将DTO映射到存储过程，以便保存、删除和查询操作。同样，这也节省了时间，因为它们中的很多最终都是非常相似的。如果您正在编写大量乏味的“咕噜”代码，请考虑使用代码生成器来完成。

后端使用实体框架或ORM映射器。这可以节省很多时间，但你必须投资于ORM知识，并学习它的工作原理。

创建一组从客户端到数据库的通用DTO。在某些情况下，当客户端需要代理或较小的DTO时，这可能并不实用，但您可以尝试使用一些从客户端一直传递到服务器的通用DTO。

移除一些图层。我知道这听起来有点反模式，但在某些情况下，洋葱不必那么厚。