Единица работы: созданная / управляемая сервисным уровнем или уровнем репозитория? C # /. NET

Question

Я читал, и теперь видел две разные реализации шаблона Unit of Work. В первом шаблоне репозиторий обращается к единице работы с объектом домена.

Другая реализация имеет уровень Service, регистрирующий объект домена как измененный:

Я предполагаю, что мой вопрос, каковы преимущества / недостатки каждого? Я знаю, что есть много ответов, не предоставляя некоторый код реализации для репозиториев / картостроителей / и т.д. ... но в целом, кто / что должен действительно отвечать за "обновление" UoW и последующую работу с ним?

Я думаю, что если вы позволите хранилищу обрабатывать его, он должен быть предоставлен как инъецируемый интерфейс к хранилищу (ам), чтобы одно и то же UoW могло охватывать несколько хранилищ (то есть несколько объектов домена) ...

Если сервисный уровень обрабатывает его, то вы «застряли» только с одной реализацией UoW на вызов сервисного уровня (например, ServiceLayer.AddCustomer (customer)).

В веб-мире я не вижу, чтобы несколько сервисных слоев вызывались для разных доменных объектов ... но, возможно, в не-сетевом мире я могу.

Я полагаю, что в конечном итоге что-то должно вызываться «commit ()», поэтому наиболее целесообразно связать это с сервисным уровнем.

Спасибо, Mike

Answer 1

Представление UoW клиентам обычно является более сильной абстракцией по сравнению с реализацией хранилища, чем использование репозитория, поскольку семантика основана на состоянии, а не на явных действиях «загрузить / сохранить / удалить».С другой стороны, четкость позволяет клиентам лучше контролировать то, что действительно происходит по беспроводной связи, с использованием спецификаций и т. Д.

IMO не существует «правильного» подхода, выбор наиболее подходящего шаблона действительно зависит от приложения.потоки данных и ограничения уровня персистенции.

Несколько мыслей-

1. Репозиторий обычно управляет одним корнем агрегатного шлюза, тогда как UoW может охватывать несколько.

2. В идеале, UoW должен быть постоянным-независимым (так как он имеет дело главным образом с состоянием объекта, таким как отслеживание изменений).Ваш маппер, очевидно, будет адаптирован к вашей реализации хранилища.Но где рассматриваются другие проблемы / обязанности хранения?Репозиторий обычно является ответом на этот вопрос.

3. Шаблон репозитория облегчает расширение решения для хранения с помощью специализированной семантики (путем добавления новых методов) или настройки внутренних реализаций (например, вызоваsproc в определенных сценариях вместо динамического кода)

Для приложения с прямыми и однородными требованиями к хранилищу прямое представление UoW является, вероятно, более простой моделью.Для более сложных сред (таких как смешанное использование динамического SQL и sprocs, устаревшие схемы и т. Д.), Репозиторий более удобен в обслуживании и расширяем, за счет того, что он немного более ограничен в использовании.

Это вневершина моей головы, надеюсь, это поможет ...

Answer 2

Даже в первом случае ваш UnitOfWork, скорее всего, будет одиночным (для каждого потока), так что даже если CustomerRepository и OtherBoilerplateExampleRepository оба обращаются к UnitOfWork до вызова коммита, коммит все равно будет использовать все изменения, сделанные всемирепозитории.

При этом, я думаю, первый шаблон - более чистый способ сделать это.При втором способе вы говорите, что CustomerService должен одновременно управлять бизнес-объектами и , чтобы зарегистрировать изменения в UnitOfWork.Это немного нарушает разделение интересов.Кроме того, не показано в этих примерах, но шаблон Repository предоставляет также место для кэширования объектов данных.

Что касается внедрения зависимостей, я думаю, вместо того, чтобы делать UoW интерфейсом для инъекций, делая шаблон Mapper(что вы видите во втором примере, но предположительно подразумевается в первом) инъекция - более подходящий выбор.Независимо от того, работаете ли вы с БД SQL, файлом XML и т. Д., Функции управления транзакциями UoW должны оставаться неизменными.