将DTO映射到域对象的最佳做法？ [英] Best Practices For Mapping DTO to Domain Object?
问题描述
我看过很多有关将DTO映射到域对象的问题，但我并没有觉得他们回答了我的问题。我以前使用过很多方法，并有自己的意见，但我正在寻找一些更具体的东西。
情况： / p>
我们有很多域对象。我们使用CSLA模型，因此我们的域对象可能非常复杂，并且包含自己的数据访问。你不想在电线上传递这些。我们将要编写一些可以以多种格式（.Net，JSON等）返回数据的新服务。为此（和其他原因），我们也在创建一个精益的数据传输对象，以便在线上传递。
我的问题是DTO和Domain对象应该如何连接？
我的第一反应是使用 Fowler，DTO模式类型解决方案。我已经看过这件事了很多次，感觉对我来说是正确的。域对象不包含对DTO的引用。调用外部实体（映射器或汇编器）从域对象创建一个DTO。通常在域对象方面有一个ORM。这样做的缺点是，映射器对于任何实际情况都趋向于非常复杂，并且可能非常脆弱。
另一个想法是让域对象包含DTO，因为它只是一个精益数据对象。域对象属性将在内部引用DTO属性，如果需要，可以返回DTO。我可以看到没有问题，但感觉错了。我看过一些文章，使用NHibernate的人似乎使用这种方法。
还有其他方法吗？上述方法之一值得使用吗？如果是，否则为什么？
感谢您提前了解。
当您只支持单个映射时，让映射器位于您的域和DTO之间的好处不是很显着，但是随着映射数量的增加，将该代码与领域有助于使域名更简单，更简洁。您不会因为您的域名而感到乱七八糟。
个人而言，我尝试将映射保留在我的域实体之外，并将责任放在我的调用管理/服务层。这是一个位于应用程序和应用程序之间的层，并提供业务逻辑，如工作流协调（如果修改A，您可能还必须修改B，以便服务A将与服务B一起使用）。
如果我有很多可能的结束格式，我可能会看看创建一个可以使用访问者模式的可插入格式化程序，例如转换我的实体，没有找到任何这个复杂的需要。
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.
The Situation:
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.
My question is how should the DTO and Domain object be connected?
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.
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.
Are there other ways? Is one of the ways above worth using? If so or if not, why?
Thanks for any insight in advance.
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.
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屋！
