Я отправил вопрос о github в команду EF. Я получил ответ о том, что было бы лучше задать этот вопрос здесь, поэтому я скопирую и вставлю его здесь, как ссылку, чтобы другие могли увидеть несколько ответов на GitHub.
Вопрос: Я проводил некоторые исследования, и кто-то указал, что в строке 24 класса DBContext указано
DbContext представляет собой комбинацию шаблонов Unit of Work и Repository.
Означает ли это, что нам больше не нужно абстрагировать EF в репозиторий, а затем использовать и интерфейс для внедрения его в контроллеры?
Оригинальный пост на Github: https://github.com/aspnet/EntityFramework/issues/4899
Причина, по которой я спрашиваю об этом, заключается в том, что я, похоже, попал в то место, где я добавляю множество репозиториев в репозиторий, таких как GetById, GetByName, GetWithIncludeABC, GetWithInclude123 и т. Д.
источник
Ответы:
Если вы добавляете методы в репозиторий, как
Тогда вам лучше перейти на сервисный уровень и позволить сервисному уровню напрямую использовать EF. EF уже имеет функциональность, аналогичную описанным выше методам, которую вы просто бесконечно дублируете.
Уровень обслуживания предоставляет методы Business Domain и использует CRUD для их реализации. Например, у вас может быть метод с именем
TransferMoney(A, B)
, где A и B проверяют счета. Это позволяет вам говорить на языке вашего бизнес-домена, а сервисный уровень обрабатывает CRUD для вас.Единственная веская причина, по которой я могу придумать, где вам может потребоваться отдельный уровень репозитория, заключается в том, что вы можете смоделировать этот уровень репозитория или заменить другой источник данных для целей тестирования.
источник
Роберт Харви сказал в своем ответе:
Именно поэтому шаблон репозитория все еще актуален. Я также не согласен с утверждением команд Entity Framework о том, что они реализуют шаблон репозитория. Entity Framework все еще очень сильно привязан к базе данных. Вся цель шаблона репозитория состоит в том, чтобы отделить и абстрагировать точный механизм персистентности, используемый в вашем приложении, чтобы ничто из реализации доступа к данным не просачивалось за пределы уровня репозитория.
Если вы используете API запросов EF вне «хранилища», как в каком-то сервисном объекте, я бы сказал, что вы нарушаете шаблон.
Теперь, если не проблема катастрофической утечки базы данных, например, функциональности, в ваш другой код, и вы можете гарантировать, что в будущем вам не нужно будет переносить некоторые из ваших операций CRUD в веб-службу, тогда использование EF напрямую будет ХОРОШО.
По сути, Entity Framework занимает место объекта Gateway в шаблоне репозитория. Я не рассматриваю это как само хранилище.
источник
TransferFunds()
иBuildWidget()
. Репозиторий просто содержит методы CRUD.Репозитории, похоже, не нужны - Microsoft в своих примерах бэкэнд-приложений для микросервисов не использует их:
https://github.com/Microsoft/BikeSharing360_BackendServices
Пример приложения BikeSharing был показан в Connect (); событие (думаю, его можно использовать как шаблон для проектов API):
https://blogs.msdn.microsoft.com/visualstudio/2016/12/14/connectdemos-2016-bikesharing360-on-github/
источник