Единица работы, хранилище, контекст

Question

Если вы посмотрите на этот вопрос SO У меня вопрос на следующем шаге.

Представьте, что у вас есть два хранилища, генерирующих Предметы и Подэлементы.У меня также есть UnitOfWork, который действует как контекст для изменений (в этом простом случае) двух разных элементов.

Кажется, есть несколько способов создания UnitOfWork, иногда это внедряется в хранилище, иногда это может быть сгенерировано фабрикой (а затем либо внедрено, либо получено с фабрики.

Мой вопрос заключается в том, как UnitOfWork уведомляет репозитории о том, что его изменения теперь должны быть зафиксированы?

Полагаю, я могу подписать репозиторий на события в UnitOfWork для фиксации / отката.

Второй вопрос, идея единицы работы состоит в том, чтобы, если у меня есть это право, координировать обновления, которые могут конфликтовать. Используя мой пример Item и SubItem (у Item есть несколько подэлементов), UnitOfWork координирует это так, что Itemсначала пишется, позволяя писать подэлемент? Теперь мне, кажется, нужна единица работы, чтобы знать о репозиториях, что кажется неправильным.

Спасибо.

Answer 1

Я структурировал свой репозиторий так, чтобы UnitOfWork был просто «токеном», порожденным методом BeginUnitOfWork () в Repo, который затем должен был быть передан практически любому другому методу в Repo, который делал DB звонки. Концептуально, единственное, что он должен знать, как это делать, это распоряжаться, что, когда это происходит, вызывает закрытие сеанса NHibernate, связанного с этим UOW. Это делается путем предоставления делегата защищенному методу в репо, который затем вызывается в его методе Dispose. То, что это делает для меня, полностью абстрагирует фактический механизм доступа к данным; Я могу реализовать один и тот же шаблон независимо от серверной части, и пользователи шаблона не могут взломать UnitOfWork, чтобы получить реальный механизм доступа к данным.

YMMV; это требует, чтобы классы, которые должны выполнять объекты БД, зависели от хранилища, а также от единицы работы. Вы можете использовать дополнительные делегаты для предоставления методов на самом UnitOfWork, которые позволят ему быть единственной зависимостью.