Question

我想开始在旧应用程序中重写（逐步）数据访问层。我们使用实体框架作为对象关系映射器，因此＆＃34;纯数据访问＆＃34;已经完成了。还需要做的是提供＆＃34; next＆＃34;层（我称之为，因为如果旧的业务层将要保留，它现在还不清楚;这可能会导致我所谈论的方法应该去哪里的问题，分层）用必要的方法获得所需的数据。

由于需要很多方法，将它们全部放在一个巨大的界面/类中并不是对我这样做的正确方法。我宁愿考虑分离这些＆＃34;获取数据＆＃34;方法主题。就是这样：

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

等等。

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

（2）我通常会在＆＃34; provider＆＃34;中积累这些接口的具体实现的创建。正如我之前在许多较小的项目中看到的那样。它通常看起来像这样（similar old question of mine，但现在我有更多的接口）：

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
    }

您可以在Here

中找到更多有用的示例

Answer 2

您正在搜索Repository Pattern并使用Unit Of Work

来利用交易

从中央类提供不同的数据访问接口：我可以/应该使用哪种模式？

2 个答案: