Czy repozytoria są już potrzebne w ASP.net 5 i EF7?

Wysłałem pytanie na github do zespołu EF. Dostałem odpowiedź, że lepiej zadać to pytanie tutaj, więc skopiuję i wkleję je tutaj jako link, aby inni mogli zobaczyć kilka odpowiedzi na GitHub.

Pytanie: Przeprowadziłem badania i ktoś zauważył, że wiersz 24 klasy DBContext stanowi

DbContext jest kombinacją wzorców jednostki pracy i repozytorium.

Czy to oznacza, że ​​nie musimy już wyodrębniać EF do repozytorium, a następnie używać i interfejsu do wstrzykiwania go do kontrolerów?

Oryginalny post na Github: https://github.com/aspnet/EntityFramework/issues/4899

Powód, dla którego o to pytam, wydaje mi się, że wchodzę w miejsce, w którym dodaję wiele metod do repozytorium, takich jak GetById, GetByName, GetWithIncludesABC, GetWithIncludes123 itd. I wydaje mi się, że w moim umyśle jest to brudne repozytorium

Jeśli dodajesz metody do repozytorium, takie jak

GetById 
GetByName 
GetWithIncludesABC
GetWithIncludes123

Następnie lepiej przejść do warstwy usług i pozwolić, aby warstwa usługi bezpośrednio korzystała z EF. EF ma już funkcjonalność podobną do powyższych metod, które duplikujesz w nieskończoność.

Warstwa usług ujawnia metody domeny biznesowej i używa CRUD do ich wdrożenia. Na przykład możesz mieć metodę o nazwie TransferMoney(A, B), w której A i B sprawdzają konta. Dzięki temu możesz mówić w języku swojej domeny biznesowej, a warstwa usługowa obsługuje CRUD.

Jedynym istotnym powodem, dla którego mogę wymyślić oddzielną warstwę repozytorium, jest wymuszenie tej warstwy repozytorium lub zastąpienie innego źródła danych do celów testowych.

Robert Harvey powiedział w swojej odpowiedzi:

Jedynym istotnym powodem, dla którego mogę wymyślić oddzielną warstwę repozytorium, jest wymuszenie tej warstwy repozytorium lub zastąpienie innego źródła danych do celów testowych.

Właśnie dlatego wzorzec repozytorium jest nadal aktualny. Nie zgadzam się również z twierdzeniem zespołów Entity Framework, że wdrażają wzorzec repozytorium. Entity Framework jest nadal bardzo związany z bazą danych. Głównym celem Wzorca Repozytorium jest odsprzęgnięcie i wyodrębnienie dokładnego mechanizmu trwałości stosowanego w aplikacji, aby nic z implementacji dostępu do danych nie wyciekło poza warstwę repozytorium.

Jeśli używasz interfejsu API zapytania EF poza „repozytorium”, jak w jakimś obiekcie usługowym, powiedziałbym, że łamiesz wzorzec.

Teraz, jeśli nie jest to katastrofalny problem dla wycieku bazy danych, takiej jak funkcjonalność bazy danych, i możesz zagwarantować, że nie będziesz musiał w przyszłości przenosić niektórych operacji CRUD do usługi internetowej, wówczas użycie EF byłoby bezpośrednie OK.

Zasadniczo Entity Framework zastępuje obiekt Gateway we wzorcu repozytorium. Nie uważam tego za samo repozytorium.

Repozytoria wydają się niepotrzebne - Microsoft w przykładowych aplikacjach mikrousług backendowych ich nie używa:

https://github.com/Microsoft/BikeSharing360_BackendServices

Przykładowa aplikacja BikeSharing została pokazana na Connect (); zdarzenie (myślę, że może być użyte jako szablon dla projektów API):

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