使用ORM实体框架的通用存储库模式+ UOW模式有什么优势

Question

让我们从两个引用开始,总结这个问题:"结束DbContext是一个漏洞的抽象.无论如何,你最终都会对服务/控制器层中的EF产生某种依赖." 引用参考 和第二个引用:

"DbContext类

表示工作单元和存储库模式的组合,使您可以查询数据库并将更改组合在一起,然后将这些更改作为一个单元写回到存储中." MSDN

请不要说存储库模式允许您简单地换出数据库,但事实并非如此.有没有人用过成熟的应用程序做过这件事？另请注意,Repository模式不应该暴露IQueryable,我认为这只是另一种说法,你不相信与你合作的人.

我完全用于封装,代码覆盖/可测试性,但由于这个流行的回购模式为EF暴露了IQueryable,它似乎不再需要这种模式:

   public interface IRepository<T> where T : class
    {
    IQueryable<T> GetAll();
    T GetById(int id);
    IEnumerable<T> Get(Expression<Func<T, bool>> filter = null,Func<IQueryable<T>,IOrderedQueryable<T>> orderBy = null, string includeProperties = "");
    void Add(T entity);
    void Update(T entity);
    void Delete(T entity);
    void Delete(int id);
}

存储库模式与UOW模式相结合的唯一好处是:1.轻松启用依赖注入模式以提高可测试性/代码覆盖率2.封装外部集成存在的复杂性(对不同供应商,Web apis,数据库的Web服务调用)等.)

那么通过使用MyDbContext:DbContext类,我得到的是什么封装？我的ORM是抽象当然我通过工作的UOW和常见的查询(如添加和删除)获得控制器的一些统一性,但这真的值得付出努力.我不能只相信我的开发人员是统一的,当他们按照自己的方式做到这一点时,就不要让OCD得到它.并且由于控制器可以编写它想要的任何查询,这不会在单元测试面前飞行吗？AND(甚至更大的大写lol)如果我有第三方API来调用,我可以在MyDbContext类中为控制器访问它,这看起来就像是对控制器的另一个数据调用.

我再说一遍,为什么不直接使用ORM,它就是数据抽象!

以下是针对存储库模式的一些参数:

http://ayende.com/blog/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer

http://ayende.com/blog/3955/repository-is-the-new-singleton

http://lostechies.com/jimmybogard/2012/09/20/limiting-your-abstractions/

http://lostechies.com/jimmybogard/2012/10/08/favor-query-objects-over-repositories/

以下是存储库模式的正确参数(尽管不够令人信服):http: //www.sapiensworks.com/blog/post/2012/10/10/Do-We-Need-The-Repository-Pattern.aspx

Answer 1

如果我再看到艾恩德的帖子,我想我会疯狂的.让我们慢慢来吧:

1. 通用存储库的适用性有限.就个人而言,我只将它用于域名存储库,并且只有当我以序列化形式存储聚合根时.对于其余的事情(阅读:视图模型,报告)我有一个存储库,专为需要这些模型的图层的需求而设计.

2. IQueryable几乎是一个查询构建器.你没有告诉存储库如何构建一些东西(IQUeryable)你只需要从中提出一些东西.如果您正在使用IQueryable,那么您已经在执行存储库工作的一部分(打破更高层的SRP).同时暴露IQueryable意味着更高层必须知道用于创建查询的pocos /实体.如果您的老板决定从现在开始您将从Web服务获取数据,您将如何处理所有那些遍布各处的IQueryable和ORM实体？或者RDBMS太慢所以让我们使用Document Db？是的,它可能会支持linq,但你确定你会定义相同的实体吗？

3. 不要相信你的开发者.相信一个适当的架构,一个不混合层责任的架构,以及尊重SRP(单一责任原则)的架构.如果您正在设计,我们假设View Models根据数据存储在db中的方式而不是根据您在视图中的需要而存在紧密耦合问题.

4. 不使用回购的原因是因为您不需要更改ORM或存储技术是恕我直言的原因类似于:为什么使用DI容器或接口,这些类很难改变,我们可以做手册无论如何注射.

5. 使用存储库意味着您无需关心模型的检索方式和位置.存储库公开了业务友好的语义(GetTopSellingProducts).使用orm你必须构建查询(每个人都喜欢在linq中进行连接和子查询),了解实体,进行投影等.为什么更高层需要关注这些细节？这是'问,不说怎么'的原则(j/k)

毕竟,这都是关于可维护代码的,我希望我的代码易于理解.