Репозиторий.
Ссылка была уже приведена, но я повторю:
http://design-pattern.ru/patterns/repository.html
Цитата:
Паттерн Repository посредничает между слоем области определения и слоем распределения данных, работая, как обычная колекция объектов области определения.
и оно понятно, сам термин Repository переводится, как
«хранилище»
Почему здесь уместны generics? Давайте посмотрим типичное переопределения DataContext:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
internal class DataContext : DbContext
{
public DataContext()
: base("DefaultConnection")
{ }
public DataContext(string connectionName)
: base(connectionName)
{ }
...
public DbSet<Customer> Customers { get; set; }
public DbSet<Order> Orders { get; set; }
...
}
В данном случае каждый DbSet<T> является репозиторием отдельной сущности. Если T имеет навигационные свойства, то через полученный объект/коллекцию, можно получить доступ к связанным объектам. Поэтому каждому отдельному репозиторию нет нужды предоставлять доп. набор методов для связанных сущностей. Правда и здесь не все так идеально, как хотелось бы. Remove() выполненный для коллекции навигационного свойства не является равнозначной инструкцией Remove() репозитория (объект не удаляется, а лишь уничтожается связь). Что логично, в принципе.
Для учебных примеров вроде сойдёт. Но теперь к боевым «реалиям».
Определяем интерфейс:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
public interface IRepository<T>
where T: class
{
int Count();
T Get(int id);
T Add(T entity);
T Update(T entity);
T Remove(T entity);
IQueryable<T> Query { get; }
}
Этого базиса хватит с головой для выполнения любых операций. Update технически не нужен для работы с EF, но должен присутствовать и использоваться.
Реализация для EF:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
internal class Repository<TEntity> : IRepository<TEntity>
where TEntity : class
{
public Repository(DbContext dbContext)
{
_dbSet = dbContext.Set<TEntity>();
}
protected IDbSet<TEntity> DbSet
{
get { return _dbSet; }
}
public TEntity Get(int id)
{
return DbSet.Find(id);
}
public TEntity Add(TEntity entity)
{
DbSet.Add(entity);
return entity;
}
public TEntity Remove(TEntity entity)
{
return DbSet.Remove(entity);
}
public TEntity Update(TEntity entity)
{
// nothing...
return entity;
}
public IQueryable<TEntity> Query
{
get { return DbSet; }
}
}
Плюсов в таком подходе достаточно:
0. Самое главное! Тестирование! Очень легко генерить коллекции и подсовывать их как источник данных.
1. Реализацию полностью можно подменить на любую другую, сменив не только базу данных, провайдер, но и ORM.
2. В отдельных случаях можно подменить реализацию репы одной сущности на другую, допустим какие-нибудь сверхогромные блобы могут храниться совсем в другой базе данных. Или отдельные данные должны храниться в более защищенном хранилище (особенно учитывая некоторые пункты Кодекса по обработке персональных данных)...
3. Можно изготовить фабрику, которая будет выдавать репу для любой запрошенной сущности, и это легко реализовать.
Далее. Расширение.
1.
2.
3.
4.
public interface IOrderRepository : IRepository<Order>
{
IQueryable<Order> VeryHeavyRecursiveQuery(params);
}
Поясню, никто не запрещает расширять репу кастомными методами, для оптимизации тех же тяжелых запросов (для которых возможностей LINQ может не хватать), в том числе если надо избавиться в некоторых случаях от Lazy-поведения.
Репозиторий должен делать только то, что должен:
«достижение полного разделения и односторонней зависимости между уровнями области определения и распределения данных» .
Все остальные задачи ложатся на другие слои бизнес-логики: менеджеры, сервисы, управление процессами, правилами и прочая хрень, что выходит за рамки
хранилища .
Пытаться пихнуть на репу каких-то еще задач, выйдет боком для сопровождения, развития и самое главное — для тестирования. Дженерики здесь очень даже уместны. Есть возражения? Примеры плз.
