背景/问题

我已经处理过许多需要持久保存数据的.NET项目,并且通常最终使用了Repository模式.有没有人知道在不牺牲代码库可扩展性的情况下删除尽可能多的样板代码的好策略？

继承战略

因为很多存储库代码都是锅炉板并且需要重复,所以我通常会创建一个基类来覆盖基本知识,例如异常处理,日志记录和事务支持以及一些基本的CRUD方法:

public abstract class BaseRepository<T> where T : IEntity
{
    protected void ExecuteQuery(Action query)
    {
        //Do Transaction Support / Error Handling / Logging
        query();
    }       

    //CRUD Methods:
    public virtual T GetByID(int id){}
    public virtual IEnumerable<T> GetAll(int id){}
    public virtual void Add (T Entity){}
    public virtual void Update(T Entity){}
    public virtual void Delete(T Entity){}
}

因此,当我有一个简单的域时,这很有效,我可以为每个实体快速创建一个DRY存储库类.但是,当域变得更复杂时,这会开始崩溃.假设引入了一个不允许更新的新实体.我可以拆分基类并将Update方法移动到另一个类中:

public abstract class BaseRepositorySimple<T> where T : IEntity
{
    protected void ExecuteQuery(Action query);

    public virtual T GetByID(int id){}
    public virtual …

让我们从两个引用开始,总结这个问题:"结束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