Правильно ли создавать UofW, чтобы делиться DbContext между репозиториями?

Question

Правильно ли создать Единицу Работы, чтобы разделить DbContext между Репозитариями?

Если нет, какова рекомендация? Я действительно думаю, что иногда нужно делиться DbContext.

Я спрашиваю об этом из-за ответа на этот вопрос: База данных в памяти не сохраняет данные

Answer 1

Правильно ли создавать Единицу Работы, чтобы делиться DbContext между Репозитариями?

Это дизайнерское решение, но да. В этом нет проблем. Абсолютно верно, что код из нескольких репозиториев выполняется при одном подключении.

Я действительно думаю, что иногда нужно делиться DbContext.

Абсолютно; Есть много раз, когда вам нужно поделиться DbContext.

Ваш связанный ответ действительно хорош. Мне особенно нравятся три упомянутых пункта. OP в этом вопросе делает некоторые ненужные сложные вещи, такие как вызовы Singleton, Service Locator и Async, не понимая, как они работают. Все это хорошие вещи, но только если они используются в нужное время в нужном месте.

Из вашего связанного ответа следует:

Лучше всего то, что всего этого можно было бы избежать, если бы люди перестали пытаться создать шаблон «Единица работы + репозиторий» на основе еще одной единицы работы и репозитория. Entity Framework Core уже реализует это:

Да; это правда. Но даже в этом случае хранилище и UoW могут быть полезны в некоторых случаях. Это дизайнерское решение, основанное на потребностях бизнеса. Я объяснил это в моих ответах ниже:

https://stackoverflow.com/a/49850950/5779732
https://stackoverflow.com/a/50877329/5779732

Использование ORM непосредственно в вызывающем коде имеет следующие проблемы:

1. Это немного усложняет код.
2. Код базы данных объединен в бизнес-логике.
3. Так как многие объекты ORM используются для вызова кода в строке, очень трудно выполнить модульное тестирование кода.

Все эти проблемы можно преодолеть путем создания конкретных хранилищ на уровне доступа к данным. DAL должен предоставлять конкретные репозитории для вызова кода (BLL или Services или Controller) через интерфейсы. Таким образом, ваша база данных и код ORM полностью используются в DAL, и вы можете легко протестировать вызывающий код модульным тестированием репозиториев. См. эту статью, объясняющую преимущества хранилища даже с ORM.

Помимо всего вышесказанного, обычно обсуждается еще одна проблема: «Что если мы решим изменить ORM в будущем». Это полностью ложно в моем личном понимании. Это случается очень редко и в большинстве случаев не должно учитываться при проектировании.

Я рекомендую избегать чрезмерного мышления и чрезмерного дизайна. Сконцентрируйтесь на целях вашего бизнеса.

См. этот пример кода, чтобы понять, как внедрить UoW в репозитории. Пример кода с Dapper. Но общий дизайн все еще может быть полезен для вас.

Answer 2

Вам нужен класс, который содержит несколько репозиториев и создает UoW. Затем, когда у вас есть сценарий использования, в котором вам нужно использовать несколько репозиториев с общим UoW, этот класс создает его и передает его в репозитории.

Обычно я называю этот класс Service, но я думаю, что не существует стандартизированного именования.