我应该将实体（持久性）对象转换为DTO对象吗？

Question

我的项目分层如下：DAL (Entity)- > BLL (DTO)- > ApplicationComponent (ViewModel)。将要ApplicationComponent访问的application（）的多个组件BLL。组件包括Windows服务，Web服务，Web API和MVC控制器。我改造NHibernate Entity的对象DTO对象，而从通过他们DAL来BLL。在将此状态传递给时ApplicationComponent，BLL再次将其转换为ViewModel。这可以帮助我区分关注点以及如何在每一层中处理数据。我不赞成NHibernate Entity出于以下原因返回对象：-数据暴露给UI我想要隐藏的（或仅在需要时暴露），例如密码，用户类型，权限等。在引用/联接上，NHibernate在访问属性时执行附加查询，这将使延迟加载的使用无效。暴露给（of Entity）用户的不必要数据会造成错误的混淆和漏洞。持久性实现泄漏到BLL/中UI。Entity不适用于UI。它不能UI在所有情况下都可用。我们在属性上使用属性DTO进行用户输入验证，看起来有点奇怪Entity。我使用这种方法面临以下问题：-最大和明显的问题是具有相似成员和功能的冗余对象。我必须在每一层中编写映射器方法以转换对象。可以通过使用AutoMapper或类似方法将其最小化；但是它不能完全解决问题。问题：-是否过度分离，应该避免（至少将其最小化）？如果这种方法是正确的，那么我看不到任何简单的方法可以完全绕开我上面提到的两个问题。请提出建议。如果此方法不正确，请提出更正建议。参考文献：Link1建议将Entity对象转移到视图，在我看来这不是一个好主意。Link2建议Entity与DTO我已经在做的映射。Link3没有帮助。Link4建议使用类似自动映射器工具的工具，这没关系。但是它仍然不能完全解决问题。Link5是很棒的帖子。它解释了为什么我应该同意将它们分开。它没有评论如何最大程度地减少由此引起的开销。Link6不再有用。Link7是这表明使用一个很好的答案Entity为是UI ，如果可能的。它仍然不适用于我的大多数项目。Linl8是另一个极好的资源，建议像我现在所做的那样以两种方式进行映射。它仍然没有建议最小化开销的方法。

Answer 1

nhibernate是使您避免拥有DAL实体的orm之一，它的性能最好避免从BLL到DAL的额外映射，但是如果对您而言并不重要，则最好将其保持在是将应用层松耦合