我有一个带有POCO域模型和NHibernate存储库层的ASP.NET MVC 2应用程序。我的域模型没有意识到我的视图模型，所以我使用了者自动模式从视图模型转向实体，反之亦然。
当我向我的项目介绍WCF（一个迟到的要求）时，我开始不得不处理断开连接的对象。也就是说，我使用NHibernate从数据库中检索实体，并且一旦该实体被序列化，它就会断开连接并且无论我是否计划使用它都会加载每个子集合，这意味着我正在做很多不必要的数据库工作。
在阅读完本文后，我发现强烈建议您不要在域项目之外公开您的实体，而应使用DTO。
我看到了这个的原因，但我无法弄清楚如何实现它。
我是否从ASP.NET MVC中的viewmodel映射到DTO，通过服务层发送DTO，并从DTO映射到服务层中的实体？我应该在哪里定义我的DTO？
答案 0 :(得分：15)
我喜欢让我的服务层保持实体封装在其中，并且只返回/接收DTO。我将服务合同以及DTO保存在MVC项目和服务实现引用的单独程序集中。
在服务调用实现中，服务将dto映射到实体，然后根据需要与存储库和其他实体进行交互。
在app / mvc项目中，我有时会变得懒惰，只使用DTO作为某些动作的模型（特别是CRUDy）。如果我需要一个投影或类似的东西，那么我将制作一个视图模型，并使用automapper等在DTO和viewmodel之间进行转换。
您的实体如何暴露是一个备受争议的主题。有些人会将它们一直推到视图/应用层。我更喜欢将它们保留在服务层中。我发现当实体离开服务层时，你会发现自己在与他们交互的地方做任何业务逻辑类型的东西，应该存在于服务中的东西。
答案 1 :(得分：2)
我将我的DTO视为ViewModel，因为UI层（MVC app）正在请求它们。你可以去实体 - ＆gt; DTO - ＆gt; ViewModel但我认为如果你的服务的唯一消费者是MVC应用程序，那就超过了工程。如果以某种方式将DTO实际用于数据而不仅仅是屏幕规范，那么你应该使用额外的映射。
我还简单地从我的WCF层返回实体，让客户端上自动生成的代理对象成为DTO。由于代理类，实体几乎成为DTO，并且没有业务逻辑传递给客户端。
当然，这完全是“它取决于”你的建筑目标。这个问题是边缘主观和议论恕我直言。
答案 2 :(得分：1)
我喜欢在MVC项目中定义DTO，然后创建扩展方法以从域实体转换为DTO（反之亦然）。
转换将在mvc函数中进行。
答案 3 :(得分：0)
我刚刚写了一篇关于绕过所有这些DTO＆lt; - ＆gt;的方法的帖子。 DO转型。也许你看看http://codeblock.engio.net/?p=17