我的项目分层如下:
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是另一个极好的资源,建议像我现在所做的那样以两种方式进行映射。它仍然没有建议最小化开销的方法。
茅侃侃
相关分类