通用存储库使用EF 4.1有什么意义 [英] Generic Repository With EF 4.1 what is the point

问题描述

当我深入研究DbContext，DbSet和关联的接口时，我想知道为什么您需要围绕这些实现来实现一个单独的通用"存储库?

As i dig deeper in to the DbContext, DbSet and associated interfaces, I am wondering why you would need to implement a separate "Generic" Repository around these implementations?

看起来DbContext和IDbSet可以满足您的所有需求，并在DbContext中包含工作单元".

It looks like DbContext and IDbSet do everything you need and include the "Unit Of Work" inside DbContext.

我在这里错过了什么吗?或者似乎人们无缘无故地喜欢添加另一层依赖.

Am I missing something here or does it seem people enjoy adding another layer of dependency for no reason.

推荐答案

您实际上是对的. DbContext是工作单元模式的实现，而IDbSet是存储库模式的实现.

You are actually right. DbContext is an implementation of the unit of work pattern and IDbSet is an implementation of the repository pattern.

存储库当前非常受欢迎且使用过度.每个人之所以使用它们，只是因为有数十篇有关为实体框架创建存储库的文章，但实际上没有人描述与该决策相关的挑战.

Repositories are currently very popular and overused. Everybody use them just because there are dozens of articles about creating repository for entity framework but nobody actually describes challenges related to this decision.

使用存储库的主要原因通常是:

Main reasons for using repository are usually:

• 从上层隐藏EF
• 使代码更易于测试

第一个原因是某种结构上的纯度和很棒的主意，如果您使上层独立于EF，则以后可以切换到其他持久性框架.您在现实世界中看到过多少次这样的事情?这个原因使使用EF变得更加困难，因为您的存储库必须提供很多其他功能，这些功能包装了EF默认情况下允许的功能.

The first reason is some kind of architectonic purity and great idea that if you make your upper layers independent on EF you can later on switch to other persistence framework. How many times did you see such thing in the real world? This reason makes working with EF much harder because your repository must expose a lot of additional features wrapping what EF allows by default.

同时包装EF代码可以使您的代码更有条理，并遵循关注点分离规则.对我来说，这可能是存储库和工作单元的唯一真正优势，但是您必须了解，遵循EF的这一规则可能会使您的代码更易于维护和可读性，但在最初创建应用程序的过程中，它将变得更高，并且对于较小的应用程序，这可能是不必要的复杂性.

In the same time wrapping EF code can keep your code better organized and following Separation of concern rule. For me this can be the only real advantage of repository and unit of work but you have to understand that following this rule with EF will maybe make your code better maintainable and better readable but in the initial effort to create your application will be much higher and for smaller applications this can be unnecessary complexity.

第二个原因部分正确. EF的最大缺点是刚性架构，几乎无法模拟，因此如果要对上层进行单元测试，则必须以某种方式包装EF来模拟其实现.但这还有许多其他后果，我在此处进行了描述.

The second reason is partially correct. The big disadvantage of EF is rigid architecture which can be hardly mocked so if you want to unit test upper layer you must wrap EF somehow to allow mocking its implementation. But this has many other consequences which I described here.

我关注 Ayende的博客.如果您曾经使用过NHibernate，那么您可能会知道他的文章.这个家伙最近写了几篇文章反对将存储库与NHibernate一起使用，但是NHibernate更好的可模拟性.

I follow Ayende's blog. If you ever used NHibernate you probably know his articles. This guy recently wrote several articles against using repository with NHibernate but NHibernate is much better mockable.

这篇关于通用存储库使用EF 4.1有什么意义的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！