Предоставлять различные интерфейсы доступа к данным из центрального класса: есть ли шаблон, который я мог/должен использовать?

Question

Я хочу начать переписывать (шаг за шагом) уровень доступа к данным в старом приложении. Мы используем Entity Framework как объектный реляционный сопоставитель, поэтому «чистый доступ к данным» уже выполнен. Что еще нужно сделать, это предоставить «следующий» слой (я называю это потому, что сейчас неясно, останется ли старый бизнес-уровень вообще, это может привести к вопросу о том, где методы, о которых я говорю должен идти по слоям) с необходимыми методами для получения требуемых данных.

Так как будет много методов, то их все в одном огромном интерфейсе/классе не кажется правильным способом сделать это со мной. Я предпочитаю разделять эти методы «получения данных» тематически. То есть примерно следующее:

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

и так далее.

(1) Как вы думаете, полезно ли использовать интерфейсы вообще (я так думаю), даже если их реализация вряд ли изменится? Я должен добавить новые методы как для интерфейса, так и для реализации.

(2) Обычно я накапливал создание конкретной реализации этих интерфейсов внутри класса «поставщик», как я видел во многих наших небольших проектах раньше. Это, как правило, выглядит следующим образом (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

Вы в поисках Repository Pattern и Усиливая сделок используют Unit Of Work

Answer 2

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

вы можете использовать хранилище шаблон и единицы работы Patterns здесь, как Что ж.

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