Луковая архитектура, единица работы и общий шаблон репозитория

Я могу сказать, что этот код достаточно хорош для первой попытки, но ему есть что улучшить.

Давайте пройдемся по некоторым из них.

1. Внедрение зависимостей (DI) и использование IoC.

Вы используете простейшую версию шаблона Service Locator - container сам экземпляр .

Я предлагаю вам использовать «инъекцию конструктора». Дополнительную информацию можно найти здесь (ASP .NET MVC 4 Dependency Injection).

public class CustomerController : Controller
{
    private readonly IUnitOfWork unitOfWork;
    private readonly ICustomerRepository customerRepository;

    public CustomerController(
        IUnitOfWork unitOfWork, 
        ICustomerRepository customerRepository)
    {
        this.unitOfWork = unitOfWork;
        this.customerRepository = customerRepository;
    }

    public ActionResult List()
    {
        return View(customerRepository.Query());
    }

    [HttpPost]
    public ActionResult Create(Customer customer)
    {
        customerRepository.Add(customer);
        unitOfWork.SaveChanges();
        return RedirectToAction("List");
    }
}

2. Объем единицы работы (UoW).

Я не могу найти образ жизни IUnitOfWork и ICustomerRepository. Я не знаком с Unity, но msdn говорит, что TransientLifetimeManager используется по умолчанию. Это означает, что вы будете получать новый экземпляр каждый раз, когда разрешаете type.

Итак, следующий тест не проходит:

[Test]
public void MyTest()
{
    var target = new UnityContainer();
    target.RegisterType<IUnitOfWork, EntityFrameworkUnitOfWork>();
    target.RegisterType<ICustomerRepository, CustomerRepository>();

    //act
    var unitOfWork1 = target.Resolve<IUnitOfWork>();
    var unitOfWork2 = target.Resolve<IUnitOfWork>();

    // assert
    // This Assert fails!
    unitOfWork1.Should().Be(unitOfWork2);
} 

И я ожидаю, что экземпляр UnitOfWork в вашем контроллере отличается от экземпляра UnitOfWork в вашем репозитории. Иногда это может привести к ошибкам. Но это не выделено в ASP. .NET MVC 4 Dependency Injection как проблема для Unity.

В Замке Виндзор PerWebRequest стиль жизни используется для совместного использования одного и того же экземпляра типа в одном HTTP-запросе.

Это распространенный подход, когда UnitOfWork является компонентом PerWebRequest. Пользовательский ActionFilter может использоваться для вызова Commit() во время вызова метода OnActionExecuted().

Я бы также переименовал метод SaveChanges() и назвал его просто Commit, как он вызывается в примере < / a> и в PoEAA.

public interface IUnitOfWork : IDisposable
{
    void Commit();
}

3.1. Зависимости от репозиториев.

Если ваши репозитории будут «пустыми», создавать для них определенные интерфейсы не нужно. Можно разрешить IRepository<Customer> и иметь следующий код в вашем контроллере

public CustomerController(
    IUnitOfWork unitOfWork, 
    IRepository<Customer> customerRepository)
{
    this.unitOfWork = unitOfWork;
    this.customerRepository = customerRepository;
}

Есть тест, который это проверяет.

[Test]
public void MyTest()
{
    var target = new UnityContainer();
    target.RegisterType<IRepository<Customer>, CustomerRepository>();

    //act
    var repository = target.Resolve<IRepository<Customer>>();

    // assert
    repository.Should().NotBeNull();
    repository.Should().BeOfType<CustomerRepository>();
}

Но если вы хотите иметь репозитории, которые представляют собой «слой абстракции над слоем сопоставления, где сконцентрирован код построения запроса». (PoEAA, репозиторий)

Репозиторий является посредником между уровнями отображения домена и данных, действуя как коллекция объектов домена в памяти. Клиентские объекты декларативно составляют спецификации запросов и отправляют их в репозиторий для удовлетворения.

3.2. Наследование EntityFrameworkRepository.

В этом случае я бы создал простой IRepository

public interface IRepository
{
    void Add(object item);

    void Remove(object item);

    IQueryable<T> Query<T>() where T : class;
}

и его реализация, которая умеет работать с инфраструктурой EntityFramework и может быть легко заменена другой (например, AzureTableStorageRepository).

public class EntityFrameworkRepository : IRepository
{
    public readonly EntityFrameworkUnitOfWork unitOfWork;

    public EntityFrameworkRepository(IUnitOfWork unitOfWork)
    {
        var entityFrameworkUnitOfWork = unitOfWork as EntityFrameworkUnitOfWork;

        if (entityFrameworkUnitOfWork == null)
        {
            throw new ArgumentOutOfRangeException("Must be of type EntityFrameworkUnitOfWork");
        }

        this.unitOfWork = entityFrameworkUnitOfWork;
    }

    public void Add(object item)
    {
        unitOfWork.GetDbSet(item.GetType()).Add(item);
    }

    public void Remove(object item)
    {
        unitOfWork.GetDbSet(item.GetType()).Remove(item);
    }

    public IQueryable<T> Query<T>() where T : class
    {
        return unitOfWork.GetDbSet<T>();
    }
}

public interface IUnitOfWork : IDisposable
{
    void Commit();
}

public class EntityFrameworkUnitOfWork : IUnitOfWork
{
    private readonly DbContext context;

    public EntityFrameworkUnitOfWork()
    {
        this.context = new CustomerContext();
    }

    internal DbSet<T> GetDbSet<T>()
        where T : class
    {
        return context.Set<T>();
    }

    internal DbSet GetDbSet(Type type)
    {
        return context.Set(type);
    }

    public void Commit()
    {
        context.SaveChanges();
    }

    public void Dispose()
    {
        context.Dispose();
    }
}

И теперь CustomerRepository может быть прокси и ссылаться на него.

public interface IRepository<T> where T : class
{
    void Add(T item);

    void Remove(T item);
}

public abstract class RepositoryBase<T> : IRepository<T> where T : class
{
    protected readonly IRepository Repository;

    protected RepositoryBase(IRepository repository)
    {
        Repository = repository;
    }

    public void Add(T item)
    {
        Repository.Add(item);
    }

    public void Remove(T item)
    {
        Repository.Remove(item);
    }
}

public interface ICustomerRepository : IRepository<Customer>
{
    IList<Customer> All();

    IList<Customer> FindByCriteria(Func<Customer, bool> criteria);
}

public class CustomerRepository : RepositoryBase<Customer>, ICustomerRepository
{
    public CustomerRepository(IRepository repository)
        : base(repository)
    { }

    public IList<Customer> All()
    {
        return Repository.Query<Customer>().ToList();
    }

    public IList<Customer> FindByCriteria(Func<Customer, bool> criteria)
    {
        return Repository.Query<Customer>().Where(criteria).ToList();
    }
}

Единственный недостаток, который я вижу, заключается в том, что вы сильно зависите от своего инструмента IOC, поэтому убедитесь, что ваша реализация надежна. Однако это характерно не только для луковых дизайнов. Я использовал Onion в ряде проектов и не сталкивался ни с какими реальными подводными камнями.

Я вижу пару серьезных проблем в коде.

Первая проблема - это взаимосвязь между репозиториями и UoW.

    var unitOfWork = container.Resolve<IUnitOfWork>();
    var customerRepository = container.Resolve<ICustomerRepository>();

Вот неявная зависимость. Репозиторий не будет работать без UoW! Не все репозитории нужно подключать к UoW. Например, как насчет хранимых процедур? У вас есть хранимая процедура и вы прячете ее за репозиторием. Вызов хранимой процедуры использует отдельную транзакцию! По крайней мере, не во всех случаях. Поэтому, если я разрешу единственный репозиторий и добавлю элемент, он не будет работать. Более того, этот код не будет работать, если я установлю Transient life license, потому что в репозитории будет другой экземпляр UoW. Итак, у нас есть сильная неявная связь.

Вторая проблема: вы создаете тесную связь между движком контейнера DI и используете его в качестве локатора сервисов! Локатор сервисов - не лучший подход для реализации IoC и агрегации. В некоторых случаях это антипаттерн. Следует использовать контейнер DI