Тема реализации паттерна Unit Of Work уже поднималась в комментариях к статье «Совершенный код. Разбор выпуска №1». После чего мне пришло множество писем с вопросами по этой теме. Одно из последних писем выношу на отдельное обсуждение.
Вопрос косвенно связан со статьей в твоем блоге «Domain-Driven Design: aggregation root».
В примерах бизнес сценариев ты используешь конструкцию:
using (unitOfWorkFactory.Create()) { var account = new Account("email", "password"); account.AddRole(Role.Admin); accountRepository.Save(account); }В общем с этой конструкцией все ясно, я также изучил набор реализаций UoW для .NET/Java инфраструктур - они все внешне сводятся к одному и тому же. Меня интересует, как реализован конкретно используемый тобой UoW, как с ним работают репозитории, что представляет из себя фабрика.
Я продолжил копаться и нашел то что в принципе полностью удовлетворяет меня на данный момент: http://github.com/riteshrao/ncommon/tree/v1.1/NCommon/src/Data
Внешне из сервиса оно выглядит примерно также как и у тебя в примерах. Внутренне существенное, что разделено UoW и Транзакционность. Unit of Work отвечает только за отслеживание изменений и Flush, когда за транзакцию отвечает отдельная компонента инфраструктуры. Объединяются они с помощью UnitOfWorkScope, что означает UoW + транзакция. Именно он и юзается в бизнес логике. Фабрика UoW скрыта внутри.
Итак, ваши примеры реализации Unit of Work, best practicies, их плюсы и минусы пишите в комментариях или мне на почту.
Как обычно я выложу лучшие советы со ссылкой на авторов и возможно своими дополнениями. Авторы решений, оставляйте, пожалуйста, свои контакты (сайты, блоги), чтобы я мог на вас ссылаться.
