将DTO映射到域对象的最佳实践？

我已经看到了许多与将DTO映射到域对象有关的问题，但是我不觉得它们回答了我的问题。我以前使用过很多方法，也有自己的见解，但我正在寻找更具体的东西。

情况：

我们有很多领域对象。我们使用CSLA模型，因此我们的域对象可能非常复杂，并且它们包含自己的数据访问权限。您不想通过导线传递这些信息。我们将要编写一些新服务，这些服务将以多种格式（.Net，JSON等）返回数据。由于这个原因（和其他原因），我们还创建了一个精益的数据传输对象，以在线上传递。

我的问题是：应该如何连接DTO和域对象？

我的第一个反应是使用Fowler DTO模式类型的解决方案。我已经看过很多次了，这对我来说感觉很对。域对象不包含对DTO的引用。调用外部实体（“映射器”或“汇编器”）以从域对象创建DTO。通常，在域对象方面有一个ORM。不利的一面是，“映射器”在任何实际情况下都变得极其复杂，并且可能非常脆弱。

提出的另一个想法是域对象“包含” DTO，因为它只是一个精益数据对象。域对象属性将在内部引用DTO属性，如果需要，可以仅返回DTO。我看不到任何问题，但感觉不对。我看过一些文章，其中使用NHibernate的人们似乎使用这种方法。

还有其他方法吗？以上方法之一值得使用吗？如果可以，为什么？

当您仅支持单个映射时，将映射器放在您的域和DTO之间的好处就不那么明显了，但是随着映射数量的增加，将代码与域隔离可以使域更简单，更精简。您不会因过多的负担而使您的域名混乱。

就我个人而言，我尝试将映射排除在我的域实体之外，并将责任放在我所谓的“经理/服务层”中。这是一个位于应用程序和存储库之间的层，并提供诸如工作流协调之类的业务逻辑（如果您修改A，则可能还必须修改B，以便服务A与服务B一起使用）。

如果我有很多可能的结尾格式，我可能会考虑创建一个可插入的格式化程序，该格式程序可以使用Visitor模式，例如来转换我的实体，但是我还没有发现需要这种复杂的格式。

您可以使用一种自动映射器，例如Jimmy Bogard编写的那种，在对象之间没有连接，并且依赖于遵守的命名约定。

我们使用T4模板来创建映射类。

Pro-在编译时可用的人类可读代码，比运行时映射器更快。100％控制代码（可以使用部分方法/模板模式临时扩展功能）

缺点-排除某些属性，域对象的集合等，学习T4语法。

将映射逻辑保留在实体内部意味着您的域对象现在知道了它不需要知道的“实现细节”。通常，DTO是您通往外界的网关（通过传入请求或通过读取外部服务/数据库）。由于实体是业务逻辑的一部分，因此最好将这些详细信息保留在实体之外。

将映射保留在其他位置是唯一的选择-但是应该去哪里？我尝试过引入映射对象/服务，但毕竟已经说完了，这似乎是过度工程（可能是）。对于较小的项目，我已经使用Automapper取得了一些成功，但是诸如Automapper之类的工具都有其自身的陷阱。我很难找到与映射有关的问题，因为Automapper的映射是隐式的，并且与其余代码完全脱钩了（不像“关注点分离”，而是更像是“被抛弃的映射存在于何处”），所以它们有时很难追踪。并不是说Automapper没有它的用​​途，因为它有用途。我只是认为映射应该尽可能明显和透明，以避免出现问题。

除了创建映射服务层之外，我在将映射保留在DTO内方面也取得了很多成功。由于DTO始终位于应用程序的边界，因此可以使他们了解业务对象并找出如何从中映射到它们。即使映射数扩展到合理的数量，它也可以正常工作。所有映射都在一个地方，您不必在数据层，反腐败层或表示层内部管理一堆映射服务。相反，映射只是委派给与请求/响应有关的DTO的实现细节。由于序列化程序通常仅在通过网络发送属性和字段时才对属性和字段进行序列化，因此您不会遇到任何问题。我个人认为这是最干净的选择，根据我的经验，

您如何看待在DTO类中实现一个将域对象作为参数的构造函数？

说...像这样

class DTO {

     // attributes 

     public DTO (DomainObject domainObject) {
          this.prop = domainObject.getProp();
     }

     // methods
}

另一个可能的解决方案：http : //glue.codeplex.com。

特征：

• 双向映射
• 自动映射
• 不同类型之间的映射
• 嵌套映射和展平
• 列表和数组
• 关系验证
• 测试映射
• 属性，字段和方法

您也可以尝试Otis，一个对象到对象的映射器。概念类似于NHibernate映射（属性或XML）。

http://code.google.com/p/otis-lib/wiki/GettingStarted

我可以建议一个我创建的工具，该工具是在CodePlex：EntitiesToDTOs上托管的开源工具。

从DTO到实体的映射，反之亦然，是通过扩展方法实现的，这些方法构成了两端的“汇编器”端。

您以如下代码结束：

Foo entity = new Foo();
FooDTO dto = entity.ToDTO();
entity = dto.ToEntity();

List<Foo> entityList = new List<Foo>();
List<FooDTO> dtoList = entityList.ToDTOs();
entityList = dtoList.ToEntities();

为什么我们不能这样做呢？

class UserDTO {
}

class AdminDTO {
}

class DomainObject {

 // attributes
 public DomainObject(DTO dto) {
      this.dto = dto;
 }     

 // methods
 public function isActive() {
      return (this.dto.getStatus() == 'ACTIVE')
 }

 public function isModeratorAdmin() {
      return (this.dto.getAdminRole() == 'moderator')
 }

}


userdto = new UserDTO();
userdto.setStatus('ACTIVE');

obj = new DomainObject(userdto)
if(obj.isActive()) {
   //print active
}

admindto = new AdminDTO();
admindto.setAdminRole('moderator');

obj = new DomainObject(admindto)
if(obj.isModeratorAdmin()) {
   //print some thing
}

@FrederikPrijck（或）某人：请提出建议。在上面的示例中，DomainObject取决于DTO。通过这种方式，我可以避免代码将dto映射到<->域对象。

还是DomainObject类可以扩展DTO类？

另一种选择是使用ModelProjector。它支持所有可能的情况，并且非常易于使用，并且占用空间最小。

我们可以为此使用Factory，Memento和Builder模式。工厂隐藏有关如何从DTO创建域模型实例的详细信息。Memento将注意域模型与DTO之间的序列化/反序列化，甚至可以访问私有成员。Builder将允许使用流畅的界面从DTO映射到域。