Просто расширяя сказанное @Fran в своем ответе и комментарии.
Контекст базы данных в большинстве случаев представляет вашу единицу работы.Имея это в виду, есть по крайней мере две причины, чтобы внедрить его в репозитории, а не создавать его в репозиториях.
Использование одного контекста в нескольких репозиториях
Во многих статьях говорится, что транзакция является ответственностьюрепозитория.Но в практическом мире, это не может иметь место каждый раз.Возможно, потребуется охватить транзакцию несколькими хранилищами.Чтобы достичь этого, нет лучшего способа, чем внедрить его.
Управление контекстом на более высоком уровне (может быть контекст на запрос в Интернете), который недоступен для репозитория
Это не сильно отличается от вышеуказанного.Многие реализации управляют контекстом на более высоком уровне, который недоступен для репозиториев.Контекст на запрос является популярным примером.В этом случае Context должен быть каким-то образом отделен от репозитория и обрабатываться иначе.Но хранилищам нужен контекст;так что просто введите его.
Контексты, предоставляемые полными ORM, реализуют отслеживание изменений в хорошем масштабе.Чтобы лучше использовать эту функцию, лучше, чтобы Context был отделен от репозиториев.
Представьте себе случай, когда ваш вызов репозитория выполнен успешно, но вы не хотите сбрасывать, потому что ваше другое действие с файлом не удалось.
Отделяя Context от Repository, вы лучше реализуете SRP.Контекст отвечает за отслеживание изменений и очистку.Хранилище хранит представление данных в памяти с изменениями, если таковые имеются, и позволяет читать / записывать эти данные в памяти.