我应该将实体（持久性）对象转换为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或类似方法将其最小化；但是它不能完全解决问题。

问题：-

1. 是否过度分离，应该避免（至少将其最小化）？
2. 如果这种方法是正确的，那么我看不到任何简单的方法可以完全绕过我上面提到的两个问题。请提出建议。
3. 如果此方法不正确，请提出更正建议。

参考文献：

1. Link1建议将Entity对象转移到视图，在我看来这不是一个好主意。
2. Link2建议Entity与DTO我已经在做的映射。
3. Link3没有帮助。
4. Link4建议使用类似自动映射器工具的工具，这没关系。但是它仍然不能完全解决问题。
5. Link5是很棒的帖子。它解释了为什么我应该同意将它们分开。它没有评论如何最大程度地减少由此引起的开销。
6. Link6不再有用。
7. Link7是这表明使用一个很好的答案Entity为是UI ，如果可能的。它仍然不适用于我的大多数项目。
8. Linl8是另一个极好的资源，建议像我现在所做的那样以两种方式进行映射。它仍然没有建议最小化开销的方法。

Answer 1

nhibernate 是允许您避免使用 DAL 实体的 orm 之一，避免从 BLL 到 DAL 的额外映射对性能会更好，但如果这对您来说并不重要，那么最好将其保持为应用层松耦合