Je suis dans le processus concevant un site Web dans ASP.NET MVC et suis peut-être un peu confus quant à la nature exacte d'un référentiel.
Après l'exemple Nerddinner, mon site doit avoir un référentiel qui sert les entités comme j'en ai besoin. Cependant, j'ai également entendu dire que vous devriez avoir des référencements différents qui traitent des ensembles spécifiques d'entités associées ...?
Dans le cas de mon site, il y aura un certain nombre d'entités (environ 15 tables) pourtant la majorité sont toutes liées. Est-ce correct / conseillé de disposer d'un référentiel contenant toutes les méthodes dont vous aurez besoin pour tirer / mettre à jour / la suppression, etc. ou dois-je les diviser?
8 Réponses :
Si vous utilisez un référentiel générique qui accepte des types, je ne vois aucune raison d'utiliser plus d'un.
Nous utilisons une interface comme ceci: P>
var returnedObjects = repository.GetAll<ObjectClass>(); var singleObject = repository.Get<ObjectClass>(id);
Je pense peut-être le verbiage de ce qu'un référentiel pourrait vous déranger. Pour moi, un référentiel est le stockage de données (c'est-à-dire la base de données MS SQL) de l'endroit où vos données sont stockées.
Suivant le Modèle de référentiel Je vous recommande de configurer un seul réservant pour chaque magasin de données. La plupart de mes projets que j'utilise MS SQL, donc je crée un référentiel pour ce dB (j'aime utiliser subsonne pour mon DAL / ORM et il met également en œuvre le motif de la reposition et le motif Actionecord) alors je crée des usines pour chaque table. Cela me permet de contourner les classes subsonsiques Activerecord et me procure une abstraction.
J'espère que c'est utile, peut-être ...
Je suis curieux de créer l'énoncé de créer un référentiel pour chaque magasin de données. Et si j'ai une "entité" nombreuses à plusieurs, cela ne fait que stocker 2 identifiants (car il s'agit de la clé primaire)? Dois-je créer un référentiel de cela, ou puis-je simplement inclure certaines des méthodes de base de l'extraction / de sauvegarde de base dans un autre référentiel associé? Je pensais que des référentiels devraient se concentrer davantage sur les entités globales.
Merci pour toutes les réponses les gars - très utile. Cet itinéraire «générique» m'a intéressé, même si vous étiez le débutant que je ne suis pas sûr de savoir comment j'allais suivre. Je suis en utilisant le cadre d'entité comme mon ormes ....
Je crée un référentiel pour chaque objet de données.
Par exemple, une base de données de bibliothèque simple pourrait contenir les référentiels suivants:
Donc, dans ce cas quel référentiel retournerait tous les livres par un auteur spécifique?
Le bibliothèque, puisque vous demandez des livres
Je vois. Peut-être que je pense à ce sujet la mauvaise façon, mais cela semble étrange .... en termes d'entités (cadre d'entité dans mon cas), je ne peux pas m'empêcher de penser que si j'ai l'auteur, alors j'ai les livres (auteur.books par exemple) . Donc, à cet égard, on semble étrange de les diviser en différents référentiels.
J'utilise un référentiel générique qui fait beaucoup pour de nombreuses entités.
Pour un plus complexe, je suis tout simplement
Dans la conception axée sur le domaine, il existe une règle que les référentiels sont des référentiels par racine globale. Vous pouvez en savoir plus sur IT ici .
Plus je lis, plus je pense que Nerddinner est trop souvent considéré comme une collection de bonnes pratiques, alors qu'il n'est absolument pas (voir Voici pour une discussion de, en particulier, le référentiel Nerdinner). C'est pourquoi les gens blâment souvent d'autres exemples de MS comme Les développeurs vont s'y déployer, élogieux
il l'accepte aveuglément comme gospel
parce qu'il vient de Microsoft (c'est
déjà bien sur son chemin). Malheureusement, tout
Développeur qui adopte son esprit va
être laissé avec une imminatrice,
Message non doublé et illisible
).
J'ai tendance à utiliser un référentiel par groupe d'actionnaires connexes. i.e orderRepository pourrait avoir:
ordre, et commande de commande.
et en aurait un autre pour, disons, client, clientprofile, etc.
Cela empêche les classes de référentiel soignées.
Davy
Queen3 a raison, vous pouvez suivre cette théorie des racines agrégées. Je regroupe fondamentalement que mon référentiel ne pense pas à des entités, mais comment ils se trouvent logiquement dans l'application que je bâtiment.
Par exemple: P>
CustomersRepository OrdersRepository ...
Vous ne devez pas créer de référentiels par chaque table. Comme le dit Queen3, vous devez créer un référentiel par racine agrégée. Comme, si les produits peuvent avoir une catégorie, le référentiel de catégorie devrait être une classe de produits imbriquée. Suivez la relation logique de domaine que les objets de domaine.