Les référentiels sont-ils nécessaires plus longtemps dans ASP.net 5 et EF7?

9

J'ai posté une question sur github à l'équipe EF. J'ai reçu une réponse disant qu'il serait préférable de poser cette question ici, donc je vais la copier et la coller ici comme nous en tant que lien afin que d'autres puissent voir les quelques réponses sur GitHub.

Question: Je faisais des recherches et quelqu'un a souligné que la ligne 24 de la classe DBContext indique

DbContext est une combinaison des modèles d'unité de travail et de référentiel.

Cela signifie-t-il que nous n'avons plus besoin d'abstraire EF dans un référentiel, puis d'utiliser et d'interface pour l'injecter dans les contrôleurs?

Message original sur Github: https://github.com/aspnet/EntityFramework/issues/4899

La raison pour laquelle je pose cette question est que je semble entrer dans un endroit où j'ajoute beaucoup de méthodes au référentiel comme GetById, GetByName, GetWithIncludesABC, GetWithIncludes123, etc. et cela semble salir le référentiel dans mon esprit

asp.net-mvc  entity-framework  repository 
— Loren.Dorez
source
1
Que pensez-vous de la réponse que Rowanmiller a donnée? Cela me semble parfaitement raisonnable.
— Robert Harvey
@RobertHarvey Oui, c'était une bonne réponse mais je veux voir ce que les autres pensent du sujet avant de prendre une décision de référentiel ou non
— Loren.Dorez
voir aussi lostechies.com/jimmybogard/2009/09/11/wither-the-repository où Bogard soutient de la même manière.
— mcknz
Mon point de vue sur la raison pour laquelle les EF (et les autres ORM) ne sont pas des référentiels .
— Eric King
Un référentiel n'aurait pas de méthode comme GetWithIncludesABC. Le modèle de référentiel est une abstraction, essentiellement, d'une table de base de données en tant que collection. Habituellement, il est possible d'interroger la collection (par exemple par LINQ), et le référentiel convertit ensuite la requête en SQL. Ce dont vous parlez ressemble plus à une passerelle de données.
— M. Cochese

Réponses:

12

Si vous ajoutez des méthodes à un référentiel comme 

GetById 
GetByName 
GetWithIncludesABC
GetWithIncludes123

Ensuite, vous feriez mieux de passer à une couche de service et de laisser la couche de service utiliser directement EF. EF a déjà des fonctionnalités similaires aux méthodes ci-dessus que vous ne faites que reproduire à l'infini.

Une couche de service expose les méthodes du domaine d'activité et utilise CRUD pour les implémenter. Par exemple, vous pouvez avoir une méthode appelée TransferMoney(A, B), où A et B vérifient les comptes. Cela vous permet de parler la langue de votre domaine d'activité, tandis que la couche Service gère le CRUD pour vous.

La seule raison convaincante pour laquelle je peux penser où vous voudrez peut-être avoir une couche de référentiel distincte est pour que vous puissiez vous moquer de cette couche de référentiel ou remplacer une source de données différente à des fins de test.

— Robert Harvey
source
Cependant, vous pouvez vous moquer de dbset ... msdn.microsoft.com/en-us/library/dn314429(v=vs.113).aspx
— S1r-Lanzelot
4

Robert Harvey a déclaré dans sa réponse:

La seule raison convaincante pour laquelle je peux penser où vous voudrez peut-être avoir une couche de référentiel distincte est pour que vous puissiez vous moquer de cette couche de référentiel ou remplacer une source de données différente à des fins de test.

C'est précisément pourquoi le modèle de référentiel est toujours pertinent. Je suis également en désaccord avec l'affirmation des équipes d'Entity Framework selon laquelle elles implémentent le modèle de référentiel. Entity Framework est toujours très lié à une base de données. L'objectif du Repository Pattern est de découpler et d'abstraire le mécanisme de persistance exact utilisé dans votre application, de sorte que rien de la mise en œuvre de l'accès aux données ne fuit en dehors de la couche de référentiel.

Si vous utilisez l'API de requête EF en dehors du "référentiel", comme dans un objet de service quelconque, je dirais que vous cassez le modèle.

Maintenant, si ce n'est pas un problème catastrophique pour une base de données comme une fonctionnalité de s'infiltrer dans votre autre code, et vous pouvez garantir que vous n'aurez pas besoin de déplacer certaines de vos opérations CRUD vers un service Web à l'avenir, alors utiliser EF directement serait D'ACCORD.

Fondamentalement, Entity Framework prend la place de l' objet Gateway dans le modèle de référentiel. Je ne le considère pas comme un référentiel lui-même.

— Greg Burghardt
source
En quoi le référentiel diffère-t-il d'un aspect de la couche de service? d'après ce que je peux trouver si je retourne IQueryable, alors je suis essentiellement un référentiel si je retourne IEnumerable, puis je suis en utilisant une couche de service. Est-ce correct? Les modèles de couche de service et de référentiel sont-ils similaires?
— Loren.Dorez
@ Loren.Dorez: une couche de service possède des méthodes spécifiques au domaine métier, comme TransferFunds()et BuildWidget(). Un référentiel ne contient que des méthodes CRUD.
— Robert Harvey
Donc, à la fois une couche de service et un référentiel accéderaient directement au DBContext? Donc, vous mettriez le CRUD dans les méthodes Repo et Get et d'autres méthodes dans la couche Service? Suis-je bien compris?
— Loren.Dorez
La couche de service peut accéder au référentiel, si vous en avez un, au lieu d'EF directement.
— Robert Harvey
@RobertHarvey Pouvez-vous me montrer un exemple en utilisant les Get Methds ci-dessus? Comme maintenant, je suis un peu confus, désolé.
— Loren.Dorez
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.