bonjour,
puis-je avoir un exemple simple de l'utilité du pattern repository,
un exemple simple avec deux class au max une interface ou deux par ex,
merci
Version imprimable
bonjour,
puis-je avoir un exemple simple de l'utilité du pattern repository,
un exemple simple avec deux class au max une interface ou deux par ex,
merci
Salut,
Voir ici:
http://www.developpez.net/forums/d63...n/#post3754805
L’intérêt et de n'avoir pratiquement aucune, voir aucune, dépendance entre tes couches et la couche de données.
Ton appli ignore donc si elle travaille en mémoire, sur du xml, du sql etc...
oui j'ai vue ce tuto ,
mais a quoi sert de definir des interface pour chaque entité avec des methode .et de les redefinir dans chaque controlleur par exemple ??
c'est ce que je comprend pas??
on cree une interface pour chaque entité avec des methode et dans chaque controlleur on redefini ces methode !!
Je ne suis pas sur de comprendre ta question.
On n'a qu'une seule interface ici, que tous les différents repository concrets doivent implémenter.
Le controlleur reçoit en paramètre de son constructeur un objet de type interface et le tour est joué.
Les méthodes ne sont pas redéfinies dans le controlleur.
on une interface : ICustomerRepository
et une class qui contiens les meme methode :CustomerRepository_LinqToSQL
( on redefini les meme methodes )
tout ça c'est pour Customer, alors pour chaque autre entité on doit faire la meme chose :
son interface avec les methodes
et une class qui implement cette interface
mais c'est du code en double !!
c quoi l'interet de tout ça ??
L'exemple donné (customers) n'est pas l'objet du pattern.
Tu peux réfléchir avec une interface générale du genre IRepository si tu préfère (dans le cadre d'un projet de taille modeste).
Si tu passe d'un mode de persistance à l'autre, il te suffit de créer un nouveau Repository et tout le reste fonctionne pareil.Citation:
c quoi l'interet de tout ça ??
Comme indiqué par l'auteur du post, c'est notamment très appréciable pour tester tes classes (tu simule à ce moment les données avec un repository TestRepository).
Enfin, et pour généraliser le concept, il est toujours recommandé de séparer les couches via des abstractions (donc techniquement des interfaces) pour les raisons évoquées ci dessus.
Ce n'est pas du code en double, c'est même tout l'inverse. L'utilisation du pattern Repository, mais plus généralement des interfaces te permet de ne pas avoir de duplication de code et de réduire le couplage entre tes classes.Citation:
Envoyé par mvc_dev
Je t'invite à refaire un petit tour sur les tutoriels concernant la Programmation Orientée Objet et ses principes fondamentaux (Encapsulation, Héritage, Spécialisation, etc...). Ça ne fait jamais de mal de revoir les bases, même pour les expérimentes. Tu as ici des articles généraux sur les Designs Patterns en .NET, et un autre très intéressant sur l'injection de dépendances.
Avoir une interface te permet aussi de faire de l'inversion de dépendances. Imagine le cas suivant, tu as deux bases de données :
- une que tu utilises avec Linq via la classe CustomerRepository_LinqToSQL
- l'autre avec Entity Framework via la classe CustomerRepository_EntityFramework.
Au niveau de ton contrôleur, manipuler l'interface ICustomerRepository te permet de t'abstraire de la notion de CustomerRepository_LinqToSQL ou CustomerRepository_EntityFramework ou CustomerRepository_Autre. Tu remarqueras que le constructeur du contrôleur HomeController de l'exemple cité plus haute te permet d'injecter le CustomerRepository de ton choix (on parle ici d'injection de dépendances par constructeur ) :
En espérant t'avoir aidé.Code:
2
3
4public HomeController(ICustomerRepository repository) { _repository = repository; }
Salut,
Je ne sais si on peut dire que j'ai utilisé le pattern repository mais un exemple concret de ce que dit Nicolas peut être trouvé dans mon dernier papier: http://immobilis.developpez.com/tuto...ity-framework/
Pour les besoins des tests j'ai réalisé une classe qui accède à des données en utilisant plusieurs fournisseurs. Sans l'utilisation de l'interface, le code aurait été beaucoup plus long.
A+
Bah a partir du moment ou tu cache l'implémentation de ton accès BDD à tes couches supérieures (via une interface) c'est du repository, donc on est en plein dedans avec ton article à mon sens.Citation:
Je ne sais si on peut dire que j'ai utilisé le pattern repository mais un exemple concret de ce que dit Nicolas peut être trouvé dans mon dernier papier: http://immobilis.developpez.com/tuto...ity-framework/