Блог

Интернет полон информации о UnitOfWork шаблоне; даже ЭТО не исключение.

Я все еще чего-то не понимаю в этом. В моем понимании UnitOfWork = Transaction in DB . Вот и все; ни больше, ни меньше.

Это правильно?

Мое замешательство связано с тем, как оно реализовано в разных ORM s. NHibernate используется ISession не только Transaction для . Dapper оставляет все на ваше усмотрение.

Мой вопрос здесь касается только шаблона проектирования без учета какой ORM -либо технологии или.

Если это больше, чем просто Transaction , пожалуйста, объясните, как.

Редактировать 1

Ссылка на эту ссылку, как предложено в ответе @David Osborne.

Единица работы отслеживает все, что вы делаете во время бизнес-транзакции, которая может повлиять на базу данных. Когда вы закончите, программа определит все, что нужно сделать, чтобы изменить базу данных в результате вашей работы.

Так что это означает UnitOfWork , что это DBTransaction и многое другое.

Ниже приведены его дополнительные обязанности: —

• Поддерживайте состояние того, что вы изменили, вставили, удалили в этом сеансе работы.

• На основе этого состояния измените базу данных по завершении работы.

Хотя в приведенной выше цитате это явно не указано, но оно также может управлять пакетной обработкой запросов.

Правильно ли я понимаю сейчас?

A UnitOfWork — это бизнес-транзакция. Не обязательно техническая транзакция (транзакция БД), но часто привязана к техническим транзакциям.

В шаблонах корпоративных приложений это определяется как

Поддерживает список объектов, на которые влияет бизнес-транзакция, и координирует внесение изменений и решение проблем параллелизма.

Он не определяет ни способ записи изменений, ни тип хранилища.

Приложение может записывать изменения в

• база данных с использованием SQL
• файловая система, использующая потоки
• служба сохранения с использованием http-запросов
• распределенный кэш или даже хранилище в памяти с использованием вызовов методов

A UnitOfWork (бизнес-транзакция) собирает изменения в бизнес-объектах и гарантирует, что другие бизнес-транзакции будут видеть только действительные бизнес-объекты.

Например, когда ваше приложение выполняет вариант использования, оно изменяет бизнес-объекты. Если две бизнес-транзакции (обычно варианты использования) выполняются параллельно, ваше приложение должно позаботиться об изменениях, которые выполняет каждая бизнес-транзакция, и о времени, когда другие бизнес-транзакции их увидят.

Технически это часто делается с использованием транзакции db. Таким образом, единицей работы обычно является транзакция БД.

Приложения, которые используют ORM-фреймворки для обработки сохраняемости, обычно имеют отношение «один к одному» между единицей работы и транзакцией БД. Таким образом, разница между единицей работы и транзакцией БД обычно не имеет значения для разработчиков.

Это происходит, AFAIK, из-за необходимости использования инструментов ORM для отслеживания состояния [сохраняемости] объектов во время логической / бизнес-транзакции.

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

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