это паттерн, и как любой другой паттерн, "хороший" он или "плохой" определяется контекстом использования. Безусловно, создавать еще одну обертку над EF по типу UserRepository это глупо, ведь класс, который наследует DbContext, автоматически сам по себе становится репозиторием. А когда настает вопрос о сменности орм, допустим с EF поменять на Telerik или Dapper, то нужно выделить интерфейс. Тогда можно к нашему контексту который наследует DbContext добавить реализацию нашего интерфейса IRepository. И все, проблема решена! Однако есть вопрос... А как дальше то действовать? У нас в IRepository будут храниться IDbSet ? тогда все равно жесткая привязка в плане зависимостей проекта к EF. У нас будут в интерфейсе методы типа GetAllUsersByID(int id) и они будут реализованы в самом AppDbContext : DbContext, IRepository ? Либо может тут как-то можно паттерн команда присобачить? Вот хорошо, AppDbContext является репозиторием. Как его поменять на другой?
Не наследуется от контекста, а принимает его как зависимость, конкретную реализацию
когда вопрос встает о том, чтобы поменять ORM тебе все равно прийдется все выкинуть
Обсуждают сегодня