3

将近一年后，我开始了一个新的 mvc 项目，这次是版本 4。我想知道以下存储库模式的实现是否弊大于利。

public interface IRepository<T> where T : class
{
    IEnumerable<T> GetAll();

    IQueryable<T> Query(Expression<Func<T, bool>> filter);

    void Add(T entity);

    void Remove(T entity);
}

public interface IUnitOfWork
{
    void Commit();
}

public interface IDbContext : IDisposable
{
    IDbSet<T> Set<T>() where T : class;

    int SaveChanges();
}

public class DbContextAdapter : IDbContext
{
    private readonly DbContext _myRealContext;

    public DbContextAdapter()
    {
        this._myRealContext = new EstafaContext();
    }

    public void Dispose()
    {
        _myRealContext.Dispose();
    }

    public IDbSet<T> Set<T>() where T : class
    {
        return _myRealContext.Set<T>();
    }

    public int SaveChanges()
    {
        return _myRealContext.SaveChanges();
    }
}

public class SqlRepository<T> : IRepository<T> where T : class
{
    private IDbSet<T> _dbSet;

    public SqlRepository(IDbContext dbContext)
    {
        this._dbSet = dbContext.Set<T>();
    }

    public IEnumerable<T> GetAll()
    {
        return this._dbSet.ToList();
    }

    public IQueryable<T> Query(Expression<Func<T, bool>> filter)
    {
        return this._dbSet.Where(filter);
    }

    public void Add(T entity)
    {
        this._dbSet.Add(entity);
    }

    public void Remove(T entity)
    {
        this._dbSet.Remove(entity);
    }
}

public class SqlUnitOfWork : IDisposable, IUnitOfWork
{
    private IDbContext _dbContext;

    private SqlRepository<Cliente> _clientes ;

    public SqlUnitOfWork()
    {
        this._dbContext = new DbContextAdapter();
    }

    public void Dispose()
    {
        if (this._dbContext != null)
        {
            this._dbContext.Dispose();
        }
        GC.SuppressFinalize(this);
    }

    public IRepository<Cliente> Clientes
    {
        get { return _clientes ?? (_clientes = new SqlRepository<Cliente>(_dbContext)); }
    }       

    public void Commit()
    {
        this._dbContext.SaveChanges();
    }
}

这样，我可以通过 SqlUnitOfWork 从一个点管理所有存储库。我在之前的项目中使用过这种设计，效果很好，但我觉得它效率不高，可能是多余的。添加这样一个抽象层值得吗？

提前致谢！

4

2 回答 2

1

尽管我的实现并不完全像您所拥有的那样，但对我来说似乎很可靠。

我通常做的唯一其他更改是为每个实体类型存储库定义特定的接口，如下所示：

public interface IClienteRepository : IRepository<Cliente>
{
  IEnumerable<Cliente> GetByName(string firstName);
  // etc
}

这样我仍然可以将所有存储库通用地用于我的 CRUD 操作，但我也可以使用相同的存储库来抽象出一些查询逻辑。您的存储库的用户应该只需要知道他们想要什么，而不是如何获得它。

当然，这有点乏味，需要您对存储库进行具体实现以添加额外的功能，但它只是封装了无论如何您都可以通过应用程序在其他地方拥有的查询逻辑。

于 2012-12-04T03:11:31.510 回答
1

我不知道它是否有更多的缺点或优点，但多年来，我发现这种类型的存储库模式越来越没用了。除非即时切换数据库或数据源是一种真正的可能性，或者如果您需要一些疯狂的模拟宇宙测试覆盖率，我认为这比它的价值更麻烦。

只是我个人的喜好，但我喜欢我的数据访问方法更明确一点。例如，如果我将模型返回到视图，它们肯定会与我数据库中的表看起来不同。所以我想要一种GetAllModelX方法，而不是一种GetAllDbTableRows方法。

那么这个转换代码将存放在哪里？在控制器中？另一个将实体转换为模型的数据访问层？甚至有正确或错误的答案吗？可能不是。

我在这里肯定是在扮演魔鬼的拥护者，但根据我的经验，我已经摆脱了这种通用存储库设计，转而支持返回/接受模型并处理所有查询/CRUDding/UnitOfWork 的数据访问层。数据库通常使用 EF。但是话又说回来，我是一个经典的单元测试人员，他不做太多的模拟，而是做更多的集成测试。

于 2012-12-04T03:27:11.213 回答