Совершенный код №2. Пример реализации Unit Of Work с NHibernate

В комментариях и письмах к статье Совершенный код №2. Реализация Unit Of Work вы предложили довольно мало реализаций. Я опишу принципы своего видения реализации и учту ваши предложения и исправления к моему коду в предыдущих статьях.

Простое, очевидное и неправильное решение

Рассмотрим бизнес-сценарий №5 из статьи про корень агрегации. Там я привел пример реализации, который использует UnitOfWork. Об этом мы поговорим дальше, а сейчас рассмотрим решение без UnitOfWork:

public class ClientService
{
    private readonly IAccountRepository accountRepository;
    private readonly IClientRepository clientRepository;
    private readonly IOrderRepository orderRepository;
    
    public ClientService(IClientRepository clientRepository, IOrderRepository orderRepository, IAccountRepository accountRepository)
    {
        this.clientRepository = clientRepository;
        this.orderRepository = orderRepository;
        this.accountRepository = accountRepository;
    }
    
    public void LockClient(int clientId)
    {
        using (var transactionScope = new TransactionScope())
        {
            // этот метод подгрузил в клиента поля Orders и Account
            Client client = clientRepository.GetById(clientId);
            
            IEnumerable<Order> notApprovedOrders = client.Orders.Where(o => o.IsApproved == false);
            
            foreach (Order order in notApprovedOrders)
            {
             client.RemoveOrder(order);
             orderRepository.Remove(order);
            }
            
            client.Account.Disable();
            
            accountRepository.Save(client.Account);
            
            transactionScope.Complete();
        }
    }
}

Все действия происходят внутри одной транзакции. Мы учли все изменения данных: удалили неподтвержденные заказы, сохранили измененный объект Account. В принципе этот код можно было бы так и оставить, но мы этого не сделаем по нескольким причинам:

• Это код доменной логики и он должен находится в корне агрегации - доменном объекте Client. Но в таком виде этот код нельзя переносить в объект Client, т.к. придется передать в него и интерфейсы репозиториев
• В коде есть явные вызовы репозиториев. Если выбирать/удалять/сохранять приходится много объектов - это создает дополнительный код с вызовами соответствующих репозиториев, а также дополнительную связность объектов. В данном случае 3 интерфейса связаны с классом ClientService
• Мы дублируем доменную логику с вызовами соответствующих репозиториев. Например, при удалении заказов вызывается сначала client.RemoveOrder, а потом удаление из БД orderRepository.Remove
• Есть шанс забыть вызвать репозиторий для одного из измененных объектов, тогда не все изменения попадут в БД

В общем, мы можем сохранять каждый измененный объект в отдельности и отслеживать какой объект был изменен, а какой нет, но это сильно запутает весь код. Гораздо проще автоматизировать всю эту работу и инкапсулировать её в одном единственном месте.

Идея шаблона Unit Of Work

Шаблон UnitOfWork - призван отслеживать все изменения данных, которые мы производим с доменной моделью в рамках бизнес-транзакции. После того, как бизнес-транзакция закрывается, все изменения попадают в БД в виде единой транзакции.

Аналог бизнес-транзации - это транзация БД, которая выполняет все SQL-запросы как единую операцию, а при завершении транзации, либо они все проходят успешно, либо ни один SQL-запрос не выполняется. Таким же образом бизнес-транзакция отслеживает все операции, которые происходят с доменными объектами в памяти и после завершения генерирует необходимые запросы к БД.

Схема работы

При использовании UnitOfWork получаем код:

public class ClientController : Controller
{
    private readonly IClientRepository clientRepository;
    private readonly IUnitOfWorkFactory unitOfWorkFactory;
    
    public ClientController(IUnitOfWorkFactory unitOfWorkFactory, IClientRepository clientRepository)
    {
        this.unitOfWorkFactory = unitOfWorkFactory;
        this.clientRepository = clientRepository;
    }
    
    public ActionResult LockClient(int clientId)
    {
        using (IUnitOfWork unitOfWork = unitOfWorkFactory.Create())
        {
            Client client = clientRepository.GetById(clientId);
            
            client.Lock();
            
            unitOfWork.Commit();
        }
        
        return View();
    }
}

Реализация функции Lock приведена в статье. При вызове Commit все изменения объектов Order, Client и Account попадут в БД. Таким образом, мы инкапсулировали всю логику отслеживания изменений данных в одном объекте - IUnitOfWork.

Основные принципы реализации

API получилось довольно красивое, теперь разберемся как же это всё работает?

Для создания единицы работы наше приложение будет использовать интерфейс IUnitOfWorkFactory. Его метод Create будет возвращать IUnitOfWork. Мы разделили интерфейсы, которые использует наше приложение напрямую и реализации этих интерфейсов исходя из принципа инверсии зависимости.

Чтобы подставить в нашем проекте конкретную реализацию вместо IUnitOfWorkFactory, мы будем использовать IoC-контейнер.

Конкретные реализации

Переходим от интерфейсов к конкретным реализациям шаблона UnitOfWork. Эти реализации могут быть двух видов:

1. Ручная реализация
2. Готовые решения из различных ORM - NHibernate (Session), Linq2Sql (DataContext) , Entity Framework (ObjectContext), LLBLGen (UnitOfWork) и т.д.

Я ещё не видел ни одной ручной реализации, которая приближались бы по качеству к UnitOfWork из готовой библиотеки. Если у вас есть пример, напиши в комментарий. Поэтому в качестве примера я выбрал готовое решение от NHibernate.

Реализация для NHibernate

Понятно, что наша обертка в виде интерфейса IUnitOfWork будет скрывать объект Session в NHibernate. Наиболее интересный момент - это связь репозиториев и текущей единицей работы.

Я выкладываю урезанный код нашей библиотеки инфрастуктуры, который подключается ко всем текущим разрабатываемым проектам. По большей части весь этот код написан моими коллегами Александром Зайцевым и Дмитрием Крючковым.

Скачать исходный код Visual Studio 2010/C# (github)

Связь компонентов:

Вам остается только унаследовать свои репозитории от BaseRepository, реализовать свой INHibernateInitializer и проставить соответствие всех интерфейсов в IoC-контейнере.

Пример реализации INHibernateInitializer:

public class FluentInitializer : INHibernateInitializer
{
    public Configuration GetConfiguration()
    {
        MsSqlConfiguration persistenceConfigurer = MsSqlConfiguration
                .MsSql2005
                .ConnectionString(connectionStringBuilder => connectionStringBuilder.FromAppSetting("ConnectionString"))
                .ProxyFactoryFactory<ProxyFactoryFactory>()
                .CurrentSessionContext<ThreadStaticSessionContext>()
                .DoNot.ShowSql();
        
        FluentConfiguration cfg = Fluently.Configure()
                .Database(persistenceConfigurer)
                .Mappings(m => m.FluentMappings.AddFromAssemblyOf<TaskMap>());
        
        return cfg.BuildConfiguration();
    }
}

Ваша реализация

Ваш проект знает только об интерфейсах IUnitOfWork и IUnitOfWorkFactory. Значит ничего не мешает заменить предложенную мой реализацию с NHibernate на любую другую. Например, если вы используете Entity Framework, то могу посоветовать статью Using Repository and Unit of Work patterns with Entity Framework 4.0. Будьте внимательны, автор в этом примере не уделяет внимания обертке с интерфейсами и использует код специфический для Entity Framework напрямую. Это опасно тем, что при смене Entity Framework на другую ORM, вам придется менять довольно много кода во всех ваших проектах.

---

Ссылки:

• P of EAA: Unit Of Work
• MSDN Magazine: The Unit Of Work Pattern And Persistence Ignorance
• LosTechies: Wither the Repository