从中心类提供不同的数据访问接口:是否有我可以/应该使用的模式

Question

我想开始（逐步）重写旧应用程序中的数据访问层。我们使用实体框架作为对象关系映射器，因此"纯数据访问"已经完成。仍然需要做的是提供"下一个"层（我之所以这样称呼它，是因为现在还不清楚旧的业务层是否会保留;这可能会导致我正在谈论的方法应该去哪里的问题，逐层）与必要的方法来获取它需要的数据。

由于需要很多方法，因此将它们全部放在一个巨大的接口/类中对我来说似乎不是正确的方法。我宁愿考虑按主题将这些"获取数据"方法分开。也就是说，像这样：

interface IBillDataAccess { .. }
interface IAttestationDataAccess { .. }
interface ICustomerDataAccess { .. }

等等。

（

1）你认为在这里使用接口有用吗（我认为是这样），即使这些接口的实现不太可能改变？我必须向接口和实现添加新方法。

（2）我通常会在"提供程序"类中积累这些接口的具体实现的创建，就像我之前在许多小型项目中看到的那样。它通常看起来像这样（类似于我的老问题，但现在我有更多的接口）：

public static class DataAccessProvider
{
  public static ICustomerDataAccess GetCustomerDataAccess()
  {
    return new CustomerDataAccess();
  }
  public static IBillDataAccess GetBillDataAccess()
  {
    return new BillDataAccess();
  }
  // and so on
}

这个设计的一些东西困扰着我，尽管我不能把手指放在上面。我相信你的意见会在这里帮助我！

另一点（与（1）相交）：我还不确定我是否喜欢DataAccess类不是静态的。但是为此使用静态类意味着我不能使用任何接口。

我很感激对此的任何投入，因为我对这一切真的很不安全，不幸的是，我通常问的人暂时不在这里。随意怀疑和批评我在上述;)中所做的任何事情

Answer 1

 public interface IRepository<T> where T:class
    {
        IQueryable<T> GetAll();
        T GetById(object id);
        void Insert(T entity);
        void Update(T entity);         
    }

您也可以在此处使用存储库模式和工作单元模式。

 public class Repository<T>:IRepository<T> where T:class
    {
        private DbContext context = null;
        private DbSet<T> dbSet = null;
        public Repository(DbContext context)
        {
            this.context = context;
            this.dbSet = context.Set<T>();
        }
        #region IRepository
        public void Insert(T entity)
        {
            dbSet.Add(entity);
        }
        public IQueryable<T> GetAll()
        {
            return dbSet;
        }
        public void Update(T entity)
        {
            if (entity == null)
                throw new ArgumentNullException("entity");
            this.context.SaveChanges();
        }
       #endregion
    }

更多工作示例，请参见此处

Answer 2

您正在寻找存储库模式，并且要利用事务，请使用工作单元