我有一个带有POCO域模型和NHibernate存储库层的ASP.NET MVC 2应用程序。我的域模型没有意识到我的视图模型，所以我使用automapper从viewmodel转到实体，反之亦然。域实体，DTO和查看模型
当我将WCF引入到我的项目中（后期要求）时，我开始必须处理断开连接的对象。也就是说，我用NHibernate从数据库中检索一个实体，一旦实体被序列化，它就会断开连接，并且每个子集合都被加载，无论我是否计划使用它，这意味着我正在做大量不必要的数据库工作。
在阅读完本文后，我发现强烈建议您不要在您的域项目之外公开您的实体，而应该使用DTO。
我看到了这个原因，但我无法弄清楚如何实现它。
我是否将视图模型映射到ASP.NET MVC中的DTO，通过服务层发送DTO，并将映射从DTO到服务层中的实体？我应该在哪里定义我的DTO？
我喜欢让我的服务层保持实体封装在其中，并且只返回/接收DTO。我将服务合同以及DTO保存在一个单独的程序集中，该程序集既包含MVC项目又包含服务实现参考。
在服务调用实现中，服务将dto映射到实体，然后根据需要与存储库和其他实体进行交互。
在应用程序/ mvc项目上，我有时会懒惰，只是使用DTO作为某些动作（尤其是CRUDy）的模型。如果我需要投影或类似的东西，那么我会制作一个viewmodel并使用automapper等在DTO和viewmodel之间进行转换。
如何暴露您的实体是一个很有争议的话题。有些人会一直推送到视图/应用层。我更愿意将它们保留在服务层中。我发现，当实体离开服务层时，你会发现自己在业务逻辑类型的任何地方都可以进行交互，而这些东西应该可能驻留在服务中。
我喜欢在MVC项目中定义DTO，然后创建扩展方法将域实体转换为DTO（反之亦然）。
转换将发生在mvc函数中。
我对待我的DTO像ViewModels，因为UI层（MVC应用程序）正在请求它们。你可以去实体 - > DTO - > ViewModel，但如果你的服务的唯一使用者是一个MVC应用程序，我认为这是工程。如果DTO实际上被用于数据而不是简单地屏幕规范，那么你应该使用额外的映射。
我也简单地从我的WCF层返回实体，并让客户端上自动生成的代理对象成为DTO。由于代理类，这些实体几乎成为DTO，并且没有业务逻辑传递给客户端。
当然，这完全是“它取决于”你的建筑目标是什么。这个问题是边缘主观和议论恕我直言。
我刚刚写了一篇关于解决所有这个DTO < - > DO转换的方法。也许你看看它http://codeblock.engio.net/?p=17
这当然是最适用于我的情况 - 我没有意识到有关于这个问题的辩论。我只是发现暴露我的服务层以外的实体正在引起我的悲痛 - 但直到我将WCF添加到项目中，我才开始遇到这些问题。 – Mayo 2011-03-17 02:03:51
我认为如果你的应用程序不是分布式的（应用程序和服务层之间没有网络间隙），那么它就少了一个问题。我见过他们主张在应用程序的所有图层中使用实体的MS文章。我还在“alt.net”类型的文章中经常看到上面的结构，它对我来说更好。这也简化了我对应用程序的思考，该服务真正成为该领域的切入点。 – Brook 2011-03-17 02:38:17