领域实体、DTO 和视图模型
我有一个 ASP.NET MVC 2 应用程序，带有 POCO 域模型和 NHibernate 存储库层。我的域模型不知道我的视图模型，因此我使用自动映射器从视图模型转到实体，反之亦然。
当我将 WCF 引入我的项目时（一个较晚的要求），我开始不得不处理断开连接的对象。也就是说，我使用 NHibernate 从数据库中检索一个实体，一旦该实体被序列化，它就会断开连接，并且无论我是否计划使用它，都会加载每个子集合，这意味着我正在做很多不必要的数据库工作。
阅读完本文后，我发现强烈建议您不要将实体暴露在域项目之外，而应该使用 DTO。
我明白了这样做的原因，但我无法弄清楚如何实现它。
我是否从视图模型映射到 ASP.NET MVC 中的 DTO，通过服务层发送 DTO，然后从 DTO 映射到服务层中的实体？我应该在哪里定义我的 DTO？
I have an ASP.NET MVC 2 application with a POCO domain model and an NHibernate repository layer. My domain model has no awareness of my viewmodels so I use automapper to go from viewmodel to entity and vice/versa.
When I introduced WCF to my project (a late requirement), I started having to deal with disconnected objects. That is, I retrieve an entity from the database with NHibernate and once that entity is serialized it becomes disconnected and each child collection is loaded regardless of whether or not I plan on using it meaning I'm doing alot of unnecessary database work.
After reading up on this, I see that it is highly recommended that you not expose your entities outside of your domain project and you should instead use DTOs.
I see the reason for this but I'm having trouble figuring out how to implement it.
Do I map from viewmodel to DTO in ASP.NET MVC, send DTOs through the service layer, and map from DTO to entity in the service layer? Where should I define my DTOs?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我喜欢让我的服务层将实体封装在其中，并且仅返回/接收 DTO。我将服务合同以及 DTO 保存在一个单独的程序集中，MVC 项目和服务实现都引用该程序集。
在服务调用实现内部，服务将 dto 映射到实体，然后根据需要与存储库和其他实体进行交互。
在 app/mvc 项目中，我有时会变得懒惰，只使用 DTO 作为某些操作（尤其是 CRUDy 操作）的模型。如果我需要投影或类似的东西，那么我将制作一个视图模型，并使用自动映射器等在 DTO 和视图模型之间进行转换。
您的实体如何暴露是一个备受争议的主题。有些人会将它们一路推到视图/应用层。我更喜欢将它们保留在服务层。我发现当实体离开服务层时，您会发现自己在与它们交互的任何地方执行业务逻辑类型的操作，这些操作可能应该驻留在服务中。
I like to have my service layer keep entities encapsulated within it, and return/receive only DTOs. I keep the service contracts as well as the DTO's in a separate assembly which both the MVC project and the Service implementation reference.
Inside the service call implementation, the service maps dto's to entities, then does the interaction with repositories and other entities as it needs to.
On the app/mvc project I sometimes will get lazy and just use DTO's as the models for certain actions (especially CRUDy ones). If i need a projection or something like that, then I'll make a viewmodel and convert between DTO and viewmodel with automapper etc.
How exposed your entities are is a subject of much debate. Some people will push them all the way to the view/app layer. I prefer to keep them in the service layer. I find that when the entities leave the service layer, you find yourself doing business logic type stuff anywhere where they're interacted with, stuff that should probably reside in a service.
我将 DTO 视为 ViewModel，因为 UI 层（MVC 应用程序）正在请求它们。你可以去实体-> DTO-> ViewModel，但我认为如果服务的唯一消费者是 MVC 应用程序，那就超出了工程范围。如果以某种方式 DTO 实际上将用于数据而不仅仅是屏幕规范，那么您可能应该使用额外的映射。
我还只是从 WCF 层返回实体，并让客户端上自动生成的代理对象作为 DTO。由于代理类，实体几乎变成了 DTO，并且没有业务逻辑传递给客户端。
当然，这完全“取决于”您的架构目标是什么。恕我直言，这个问题是主观和争论的边缘。
I treat my DTOs like ViewModels because the UI layer ( MVC app ) is requesting them. You could go Entity -> DTO -> ViewModel but I think thats over engineering if the only consumer of your service is an MVC application. If somehow the DTOs will actually be used for data and not simply screen specifications then you should probably use additional mapping.
I've also simply returned entities from my WCF layer and let the automatically generated proxy objects on the client be the DTO. The entities almost become DTOs because of the proxy classes and no business logic comes over to the client.
And of course, this is all "It Depends" what your architectural goals are. This question is borderline subjective and argumentative IMHO.
我喜欢在 MVC 项目中定义 DTO，然后创建扩展方法以从域实体转换为 DTO（反之亦然）。
转换将在 mvc 函数中进行。
I like defining the DTO in the MVC project and then creating extension methods to transform from domain entity to DTO (and vice-versa).
The transformation would take place in the mvc functions.
我刚刚写了一篇关于绕过所有这些 DTO <-> 的方法的文章。做转型。也许你可以看看http://codeblock.engio.net/?p=17
I just wrote a post about a way of getting around all this DTO <-> DO transformation. Maybe you check it out http://codeblock.engio.net/?p=17