将 DTO 映射到域对象的最佳实践? [英] Best Practices For Mapping DTO to Domain Object?

问题描述

我已经看到很多与将 DTO 映射到域对象相关的问题，但我不觉得他们回答了我的问题.我以前用过很多方法，也有自己的看法，但我正在寻找更具体的方法.

I've seen a lot of questions related to mapping DTOs to Domain Objects, but I didn't feel they answered my question. I've used many methods before and have my own opinions but I'm looking for something a little more concrete.

情况:

我们有很多领域对象.我们使用的是 CSLA 模型，因此我们的域对象可能非常复杂，并且它们包含自己的数据访问权限.你不想在电线上传递这些.我们将编写一些新服务，以多种格式(.Net、JSON 等)返回数据.出于这个(和其他原因)，我们还创建了一个精简的数据传输对象，以便在线路上传递.

We have many domain objects. We are using a CSLA model so our domain objects can be pretty complex and they contain their own data access. You do not want to pass these around on the wire. We are going to be writing some new services that will return data in a number of formats (.Net, JSON, etc.). For this (and other reasons) we are also creating a lean, data transfer object to pass around on the wire.

我的问题是:DTO和Domain对象应该如何连接?

我的第一反应是使用 Fowler、DTO 模式类型解决方案.我已经多次看到这样做了，这对我来说是正确的.域对象不包含对 DTO 的引用.调用外部实体(映射器"或汇编器")以从域对象创建 DTO.通常在域对象端有一个 ORM.这样做的缺点是映射器"在任何实际情况下都会变得极其复杂，并且可能非常脆弱.

My first reaction is to use a Fowler, DTO pattern-type solution. I've seen this done many times and it feels right to me. The domain object contains no reference to the DTO. An outside entity (a "mapper" or "assembler") is called to create a DTO from a Domain Object. Normally there is an ORM on the domain object side. The downside of this is that the "mapper" tends to get extremely complex for any real situation and can be very fragile.

提出的另一个想法是让域对象包含"DTO，因为它只是一个精简的数据对象.域对象属性将在内部引用 DTO 属性，并且可以在需要时返回 DTO.我看不出这有什么问题，但感觉不对.我看过一些文章，其中使用 NHibernate 的人似乎使用了这种方法.

Another idea put forth is for the Domain Object to "contain" the DTO, since it's just a lean data object. The Domain Object properties would internally reference the DTO properties and could just return the DTO if asked for. I can see no problems with this but it feels wrong. I have seen some articles where people using NHibernate appeared to use this method.

还有其他方法吗?上述方法之一值得使用吗?如果是或不是，为什么?

推荐答案

在你的域和你的 DTO 之间放置一个映射器的好处并不像你只支持一个映射时那么明显，而是因为映射的数量增加，将代码与域隔离有助于使域更简单、更精简.您的域不会被大量额外的权重弄得乱七八糟.

A benefit of having a mapper that sits between your domain and your DTO is not as appearent when you are only supporting a single mapping, but as the number of mappings increases, having that code isolated from the domain helps keep the domain simpler and leaner. You won't be cluttering your domain with a lot of extra weight.

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

Personally, I try and keep the mapping out of my domain entities and put the responsibility in what I call "Manager / Service layer". This is a layer that sits between the application and the respository(ies), and provides business logic such as workflow coordination (If you modify A, you might have to also modify B so service A will work with Service B).

如果我有很多可能的结束格式，我可能会考虑创建一个可以使用访问者模式的可插入格式化程序，例如转换我的实体，但我还没有发现需要任何如此复杂的东西.

If I had a lot of possible ending formats, I might look at creating a plugable formatter that could use the Visitor pattern, for example to transform my entities, but I've not found a need yet for anything this complex.

这篇关于将 DTO 映射到域对象的最佳实践?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！