Нужны ли репозитории в ASP.net 5 и EF7?

Я отправил вопрос о github в команду EF. Я получил ответ о том, что было бы лучше задать этот вопрос здесь, поэтому я скопирую и вставлю его здесь, как ссылку, чтобы другие могли увидеть несколько ответов на GitHub.

Вопрос: Я проводил некоторые исследования, и кто-то указал, что в строке 24 класса DBContext указано

DbContext представляет собой комбинацию шаблонов Unit of Work и Repository.

Означает ли это, что нам больше не нужно абстрагировать EF в репозиторий, а затем использовать и интерфейс для внедрения его в контроллеры?

Оригинальный пост на Github: https://github.com/aspnet/EntityFramework/issues/4899

Причина, по которой я спрашиваю об этом, заключается в том, что я, похоже, попал в то место, где я добавляю множество репозиториев в репозиторий, таких как GetById, GetByName, GetWithIncludeABC, GetWithInclude123 и т. Д.

asp.net-mvc entity-framework repository

— Loren.Dorez
источник

Что вы думаете об ответе rowanmiller? Кажется вполне разумным для меня.

— Роберт Харви

@RobertHarvey Да, это был хороший ответ, но я хочу посмотреть, как другие относятся к этой теме, прежде чем я

— приму

см. также lostechies.com/jimmybogard/2009/09/11/wither-the-repository, где Богард утверждает аналогично.

— MKNZ

Я понимаю, почему EF (и другие ORM) не являются репозиториями .

— Эрик Кинг,

Хранилище не будет иметь такой метод, как GetWithIncludesABC. Шаблон репозитория представляет собой абстракцию таблицы базы данных как коллекции. Обычно можно запросить коллекцию (например, с помощью LINQ), а затем хранилище преобразует запрос в SQL. То, о чем вы говорите, больше похоже на шлюз данных.

— Мистер Кочезе

Ответы:

Если вы добавляете методы в репозиторий, как

GetById 
GetByName 
GetWithIncludesABC
GetWithIncludes123

Тогда вам лучше перейти на сервисный уровень и позволить сервисному уровню напрямую использовать EF. EF уже имеет функциональность, аналогичную описанным выше методам, которую вы просто бесконечно дублируете.

Уровень обслуживания предоставляет методы Business Domain и использует CRUD для их реализации. Например, у вас может быть метод с именем TransferMoney(A, B), где A и B проверяют счета. Это позволяет вам говорить на языке вашего бизнес-домена, а сервисный уровень обрабатывает CRUD для вас.

Единственная веская причина, по которой я могу придумать, где вам может потребоваться отдельный уровень репозитория, заключается в том, что вы можете смоделировать этот уровень репозитория или заменить другой источник данных для целей тестирования.

— Роберт Харви
источник

Однако вы можете смоделировать dbset ... msdn.microsoft.com/en-us/library/dn314429(v=vs.113).aspx

— S1r-Lanzelot

Роберт Харви сказал в своем ответе:

Единственная веская причина, по которой я могу придумать, где вам может потребоваться отдельный уровень репозитория, заключается в том, что вы можете смоделировать этот уровень репозитория или заменить другой источник данных для целей тестирования.

Именно поэтому шаблон репозитория все еще актуален. Я также не согласен с утверждением команд Entity Framework о том, что они реализуют шаблон репозитория. Entity Framework все еще очень сильно привязан к базе данных. Вся цель шаблона репозитория состоит в том, чтобы отделить и абстрагировать точный механизм персистентности, используемый в вашем приложении, чтобы ничто из реализации доступа к данным не просачивалось за пределы уровня репозитория.

Если вы используете API запросов EF вне «хранилища», как в каком-то сервисном объекте, я бы сказал, что вы нарушаете шаблон.

Теперь, если не проблема катастрофической утечки базы данных, например, функциональности, в ваш другой код, и вы можете гарантировать, что в будущем вам не нужно будет переносить некоторые из ваших операций CRUD в веб-службу, тогда использование EF напрямую будет ХОРОШО.

По сути, Entity Framework занимает место объекта Gateway в шаблоне репозитория. Я не рассматриваю это как само хранилище.

— Грег Бургхардт
источник

Чем репозиторий отличается от аспекта сервисного уровня? из того, что я могу найти, если я возвращаю IQueryable, то я по сути Repository, если я возвращаю IEnumerable, то я использую сервисный уровень. Это правильно? Схожи ли шаблоны сервисного уровня и репозитория?

— Loren.Dorez

@ Loren.Dorez: Сервисный уровень имеет методы, специфичные для бизнес-доменов, такие как TransferFunds()и BuildWidget(). Репозиторий просто содержит методы CRUD.

— Роберт Харви

Таким образом, сервисный уровень и репозиторий будут иметь прямой доступ к DBContext? Таким образом, вы бы поместили CRUD в Repo и Get Methods и другие методы в Service Layer? Я правильно понял?

— Loren.Dorez

Сервисный уровень может обращаться к репозиторию, если он у вас есть, вместо EF напрямую.

— Роберт Харви

@RobertHarvey Можете ли вы показать мне пример, используя приведенный выше метод Get Methds? Как сейчас я немного смущен извините.

— Loren.Dorez

Репозитории, похоже, не нужны - Microsoft в своих примерах бэкэнд-приложений для микросервисов не использует их:

https://github.com/Microsoft/BikeSharing360_BackendServices

Пример приложения BikeSharing был показан в Connect (); событие (думаю, его можно использовать как шаблон для проектов API):

https://blogs.msdn.microsoft.com/visualstudio/2016/12/14/connectdemos-2016-bikesharing360-on-github/

— Павел Бирюков
источник