实体框架,应用程序层和关注点分离

Question

我正在为我的应用程序使用Entity Framework 4.1和ASP.Net MVC 3.MVC提供了表示层,一个中间库提供了业务逻辑,实体框架类似于我猜的数据层？

我可以将实体框架代码分成一组存储库类,或者适当的变体,无论构成一个有价值的数据层,但是我在解决我遇到的设计问题时遇到了问题.

如果存在多层方法来帮助我将问题分开,那么我选择的数据持久性也应该不是表示层的关注点.问题在于,通过使用实体框架,我基本上将我的应用程序紧密地耦合到实体更改被跟踪和自动持久化的概念.

因此,假设在一个假设的世界中,我发现了一个不使用实体框架并希望将其交换掉的理由.一个设计良好的解决方案应该允许我在适当的层执行此操作并且不会影响依赖层,但是因为所有代码都是在数据层跟踪对象更改的情况下编写的,所以我只能交换实体以类似方式工作的东西的框架,例如nHibernate.

如何使用实体框架但不需要以假定数据层正在跟踪实体更改的方式编写我的代码？

对于那些仍然在自己的场景中对这个问题感到疑惑的人的更新:
Ayende Rahien写了一篇很棒的文章,打破了整个论点:http: //ayende.com/blog/4567/the-false-myth-of-encapsulating-data-access -in最DAL

Answer 1

如果你想继续这种方式,你应该放弃编程工作,去学习哲学.实体框架是持久性的抽象,并且有一个Leaky抽象规则,它说任何非平凡的抽象都在某种程度上是漏洞的.

敏捷方法带来了非常有趣的现象:不要为假设情况做好准备.大多数时候它只是镀金.每次更改都有其成本.在项目后期更改持久层是昂贵的,但也非常罕见.从客户的角度来看,没有理由在大多数不需要这种变化的项目中支付部分成本.如果我们更深入地讨论客户的观点,我们可以说他根本不应该为此付出代价,因为选择不好的API,以后必须更换的是开发人员/架构师的失败.定期重构您的代码,但仅限于添加客户想要的新功能所需的点,否则您将难以在市场上竞争.这当然有一些例外:

• 客户想要(或架构要求它出于任何原因,客户同意它)这样的抽象.在这种情况下,您必须使用它并定义架构以进行此类更改.
• 这是一个业余爱好或开源项目,你可以做你想做的事情,因为它不受某些资源的限制

现在你的问题.如果您想要这样的高级抽象,则不应将实体暴露给控制器.从业务层(甚至从存储库)公开DTO,并向这些DTO添加IsNew,IsModified,IsDeleted等字段.现在您的UI与持久性完全分离,但您的体系结构要复杂得多,并且可能没有理由存在这种复杂性 - 它已经过度架构.另一种方法可以简单地关闭跟踪(添加AsNoTracking()到每个查询)和实体上的代理创建(context.Configuration.ProxyCreationEnabled) - 延迟加载也不会起作用.这就像丢弃了持久性框架为您提供的大多数功能.

还有其他观点.我建议你阅读Ayende最近关于存储库的帖子以及他对Sharp架构的评论.