Explication étape par étape du modèle de référentiel [fermé]

276

Quelqu'un peut-il m'expliquer le modèle de référentiel dans .NET, étape par étape, en donnant un exemple ou une démonstration très simple.

Je sais que c'est une question très courante, mais jusqu'à présent, je n'ai pas trouvé de réponse satisfaisante.

c# asp.net design-patterns repository Sa Patil
la source
1
msdn.microsoft.com/en-us/library/ff649690.aspx et codeproject.com/Tips/309753/...
Maarten
1
Il y a un bon article ici: deviq.com/repository-pattern
ssmith

Réponses:

199

En résumé, je décrirais l'impact plus large du modèle de référentiel. Il permet à tout votre code d'utiliser des objets sans avoir à savoir comment les objets sont persistants. Toute la connaissance de la persistance, y compris le mappage des tables aux objets, est contenue en toute sécurité dans le référentiel.

Très souvent, vous trouverez des requêtes SQL dispersées dans la base de code et lorsque vous venez d'ajouter une colonne à une table, vous devez rechercher des fichiers de code pour essayer de trouver les utilisations d'une table. L'impact du changement est considérable.

Avec le modèle de référentiel, vous n'auriez besoin de modifier qu'un seul objet et un seul référentiel. L'impact est très faible.

Il serait peut-être utile de réfléchir à la raison pour laquelle vous utiliseriez le modèle de référentiel. Voici quelques raisons:

  • Vous avez un seul endroit pour apporter des modifications à votre accès aux données

  • Vous avez un seul endroit responsable d'un ensemble de tables (généralement)

  • Il est facile de remplacer un référentiel par une fausse implémentation pour les tests - vous n'avez donc pas besoin d'avoir une base de données disponible pour vos tests unitaires

Il y a aussi d'autres avantages, par exemple, si vous utilisiez MySQL et que vous vouliez passer à SQL Server - mais je n'ai jamais vraiment vu cela en pratique!

Fenton
la source
28
En passant de dbms a à b, je vais enregistrer que non seulement j'ai vu cela, mais je l'ai fait dans le code de production. Nous utilisions auparavant Oracle, nous devions changer de fournisseur d'hébergement, installés sur Azure (avant de prendre en charge Oracle), nous avons donc dû convertir en SQL Azure. Malheureusement, nous n'avions pas séparé toutes les logiques d'accès aux données à ce stade, mais nous l'avons certainement fait en procédant à cette migration (et à l'avenir, je pourrais ajouter).
Joe
5
Je sais que ce commentaire est ancien et fermé comme hors sujet, mais je l'ai vu faire dans plusieurs entreprises. Généralement, cela fait partie d'un processus pour se rapprocher ou s'éloigner d'un ORM. Le référentiel facilite sa désactivation, surtout si vous les chargez à partir d'un modèle d'usine abstrait ou à l'aide d'un conteneur IoC.
Derek Van Cuyk
En fait, le référentiel utilise DAO pour ses opérations liées aux sources de données ...
Yousha Aleayoub
1
@YoushaAleayoub qu'un bon point que vous soulevez. Vous trouverez généralement des objets d'accès aux données lorsque les gens essaient de «séparer la base de données» et des référentiels lorsque les gens essaient de «rendre une seule chose responsable de la requête». Dans presque tous les cas, vous trouverez les deux ensemble. La partie de la DAO est IConnection, ICommandetc partie qui cache le type de base. Le référentiel est généralement plus centré sur le domaine.
Fenton
181

Voici un bel exemple: l'exemple de modèle de référentiel en C #

Fondamentalement, le référentiel masque les détails de la façon dont les données sont récupérées / conservées de / vers la base de données. Sous les couvertures:

  • pour la lecture, il crée la requête satisfaisant aux critères fournis et renvoie l'ensemble de résultats
  • pour l'écriture, il émet les commandes nécessaires pour que le moteur de persistance sous-jacent (par exemple une base de données SQL) enregistre les données
deux fleurs
la source
13
Cet exemple est la meilleure explication de tous les temps, simplement meilleur que la documentation MSDN.
Teoman shipahi
2
J'ai trouvé ça très bien. Il fournit également une explication décente sur l'unité de travail, qui semble être une forme plus générique du modèle de données sur le modèle de référentiel
Celdor
8
L'exemple lié est une défaillance du modèle de référentiel. Il ne donne aucun avantage par rapport à l'utilisation directe des interfaces fournies par Entity Framework ( IDbContext) ou dans nhibernate ( ISession). Un référentiel correctement implémenté résume TOUTES les informations spécifiques à la persistance (comme le fonctionnement du fournisseur Linq To Sql actuel). c'est-à-dire ne jamais exposer IQueryable.
jgauffin
3
@jgauffin IQueryablen'est pas une information spécifique à la persistance. Le support de IQueryable peut être aussi simple qu'un tableau codé en dur, ou il peut provenir d'un fichier XML, d'un service Web, d'une base de données, d'un fichier plat, etc. Je ne recommanderais pas un référentiel qui n'exposerait pas IQueryable comme toujours conduit à un accès aux données lent dans tous les cas, où l'exposition à IQueryable permettra à certaines instances d'améliorer les performances, le cas échéant, si le magasin de persistance a cette capacité. De plus, masquer DbContext vous permet de passer à un autre ORM si besoin est (ou pas d'ORM!)
Robert McKee
5
Il fuit des informations spécifiques aux informations de persistance. Essayez d'utiliser un chargement impatient / paresseux ou de créer une INclause sql sans savoir comment le fournisseur LinqToSql spécifique le fait.
jgauffin