Это довольно плохая практика для доступа к DbContext в приложении?

Question

Я обычно вижу образцы шаблонов репозитория, которые инкапсулируют методы CRUD и даже упрощают методы расширения. Мне было очень неприятно создавать методы репозитория, которые я уже могу легко использовать с помощью DbContext. Если причина заключается в создании слабой связи между DbContext и целым приложением, поэтому мы уже можем сделать это, извлекая DbContext для интерфейса и используя его во всем приложении.

Так что выглядит лучше получить доступ к DbContext в качестве члена репозитория для таких простых методов, а не оборачивать их репозиторием. Что ты думаешь?

Answer 1

Хотя в принципе я согласен с идеями StriplingWarrior, если вы создаете более простую архитектуру, в которой ваш бизнес-уровень использует свойства / методы DbContext, в этом нет ничего плохого, особенно если вы используете интерфейс для DbContext и внедряете его.

Не забудьте также использовать IDbSet вместо DbSet, чтобы его было легко смоделировать.

Answer 2

Использование DbContext непосредственно внутри бизнес-логики или (не дай бог!) Кода логики отображения является серьезным нарушением принципа «разделения интересов» и приводит к созданию вашего кода:

• Сложнее в обслуживании: если вы решили реорганизовать способ создания вашего DbContext, теперь вам нужно просматривать всю свою кодовую базу, чтобы менять каждый new DbContext.
• Сложнее для модульного тестирования: общеизвестно, что контексты Entity Framework трудно "смоделировать", в то время как простой метод хранилища в интерфейсе можно легко смоделировать для возврата некоторых образцов данных.