Является ли плохой идеей одновременное открытие нескольких экземпляров UnitOfWork (ASP.Net Applicaiton)?

Question

У меня есть приложение, над которым я работаю, использующее Entity Framework 4.1 в качестве слоя доступа к данным.Я создал несколько репозиториев, которые работают с разными сущностями.Каждый репозиторий, как часть конструктора, принимает объект UnitOfWork.Затем я создал абстракцию для этих хранилищ со слоями служб.Каждый слой создает UnitOfWork, который затем передается в соответствующий репозиторий.

Должен ли я на моем уровне обслуживания открывать только одно UOW, которое может использоваться всеми службами, которые я создал?Я еще не сталкивался с какими-либо проблемами, но хотел знать, может ли то, что я делаю, вызывать проблемы.

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

Answer 1

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

Для простоты (а в большинстве случаев этого достаточно) разработчики обычно используют новую единицу работы для каждого запроса, поскольку каждый запрос обычно представляет одну логическую операцию. Но вы можете найти сценарии, где этого будет недостаточно. В таком случае вам потребуется несколько единиц работы и, возможно, несколько репозиториев (каждый набор связан с одной единицей работы).

Answer 2

Нет, у вас должен быть только один открытый UoW одновременно.Я бы порекомендовал использовать Factory для предоставления единственного экземпляра вашего UoW на HTTP-запрос.

Пример реализации можно найти здесь: Entity Framework 4 CTP 4 / CTP 5 Универсальный шаблон репозитория и тестируемый модуль

Answer 3

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

Предполагая, что у вас есть бизнес-уровень с именем .Task или чем-то подобным, каждая задача должна создавать единицу работы и передавать ее в вызываемые репозитории, поскольку это задача, а не репо, которая должна знать, как сущности должны быть сведены вместе.

Можно иметь по умолчанию репо по умолчанию UOW, если оно не предусмотрено, но это может привести к слабому кодированию задачи, когда вы в конечном итоге создаете репо без UOW, а затем используете его выход в чем-то, что имеет свой собственный UOW.

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