В EF DbContext и DbSet<T>, вообще говоря, реализуют из коробки соответственно UnitOfWork и Repository. Во всяком случае, сложилось такое мнение.
Погуглил на этут тему, а там народ, следуя четко по букварям оборачивает их руками в свои классы, которые реализуют свои интерфейсы интерфейсы. Т. е. вводят что-то вроде:
IRepository<T>, IUnitOfWork
1.
2.
3.
4.
5.
6.
7.
8.
9.
public interface IRepository<T> : IDisposable
where T : class
{
IQueryable<T> Entities();
void Update(T entity);
void Add(T entity);
void Remove(T entity);
bool Contains(T entity);
}
1.
2.
3.
4.
5.
public interface IUnitOfWork : IDisposable
{
IRepository<T> GetRepository<T>() where T : class;
void SaveAllChanges();
}
Реализуют что-то вроде такого:
EfRepository<T>, EfUnitOfWork
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
internal class EfRepository<T> : IRepository<T>
where T: class
{
public EfRepository(DbsET<t> dbSet)
{
_dbSet = dbSet;
}
...
{
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.
internal class EfUnitOfWork : IUnitOfWork
{
private DbContext _dbContext;
public EfUnitOfWork(DbContext dbContext)
{
_dbContext = dbContext;
}
public IRepository<T> GetRepository<T>()
where T : class
{
return new EfRepository<T>(_dbContext.DbSet<T>());
}
public void SaveAllChanges()
{
_dbContext.SaveChanges();
}
public void Dispose()
{
_dbContext.Dispose();
}
}
Используют как-то так:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
using (var uow = MyFakeUnitOfWorkFactory.Create())
{
var orderRepo = uow.GetRepository<Order>();
var z = from o in orderRepo.Entities()
select o;
...
uow.SaveAllChanges();
}
Вопрос в следующем и относится исключительно к случаю,
когда используется EF Designer .
Если поколупаться, для генерации Context'a используюься tt, которые можно менять как угодно, чтобы те выдавали уже готовые, какие надо классы обертки для контекста, дбсетов, чтобы оно само добавляло в наследование какие надо интерфейсы IUnitOfWork, IRepository и т. п.. Вопрос, почему так не делают через tt или я плохо искал или кто-то делает? Поделитесь впечатлениями/подходами.
Вопрос второй, предположим мы абстрагировались с помощью интерфейсов по самое не могу от "инфраструктурной черни по книжкам умных дядек", и в нашей DomainModel'и ссылаемся на инфраструктурный слой исключительно по интерфейсам, возникает вопрос, как быть с Disconnected сценарием, когда граф обьектов приходит извне и его надо сохранить. В общем случае без ObjectStateManager здесь не выкрутиться. В голову приходит использовать какие-нибудь self tracking entities с контекстом, который их понимает (т. е. шаблон генерящий entities, генерирует их как self tracked и шаблон генерирующий контекст, делает его понимающим self tracked сущности. т. е. предполагается менять tt которые создаются вместе с edmx для достижения такого результата).
Это все пока высосанное из пальца "...а что если вдруг?...". У кого какие соображения и т. п.. Интересно знать для понимания границ применимости и т. п..
