Repository Pattern Question

Question

Je crée une application ASP.NET MVC et j'utilise un référentiel pour stocker et récupérer des objets de vue. Ma question est la suivante: est-ce que la mise en œuvre des divers référentiels peut s'appeler? C'EST À DIRE. l'implémentation ICustomerRepository peut-elle appeler une implémentation de IAddressRepository ou doit-elle gérer ses propres mises à jour de la source de données d'adresse?

EDIT:

Merci tout le monde, l'exemple client/adresse n'est pas réelle. Le problème réel implique trois agrégats qui mettent à jour un quatrième agrégat en réponse à des changements dans leurs états respectifs. Dans ce cas, il semble qu'il y ait un conflit entre l'introduction de dépendances et la violation du principe de ne pas se répéter.

Answer 1

Vous devez disposer d'un référentiel pour chaque racine agrégée.

Je n'ai aucune connaissance de votre domaine-modèle, mais il ne me semble pas naturel d'avoir un IAddressRepository. Sauf si "Adresse" est une racine agrégée dans votre domaine.

En fait, dans la plupart des cas, 'Address' n'est même pas une entité, mais un objet de valeur. C'est-à-dire que, dans la plupart des cas, l'identité d'une "adresse" est déterminée par sa valeur (la valeur de toutes ses propriétés); il n'a pas de champ 'Id' (clé) séparé.
Ainsi, lorsque c'est le cas, CustomerRepository devrait être responsable du stockage de l'adresse, étant donné que l'adresse fait partie de la racine d'agrégat du client.

Modifier (ok si votre situation était juste un exemple):

Mais, si vous avez d'autres situations où vous auriez besoin un autre dépôt dans un dépôt, alors je pense qu'il est préférable de supprimer cette fonctionnalité hors de ce référentiel, et le mettre dans une classe distincte (Service). Je veux dire: je pense que si vous avez des fonctionnalités dans un référentiel A qui repose sur un autre référentiel B, alors ce type de fonctionnalité n'appartient pas au référentiel A.
A la place, écrivez une autre classe (appelée Service dans DDD), dans lequel vous implémentez cette fonctionnalité.

De toute façon, je ne pense pas que les dépôts devraient vraiment s'appeler. Si vous ne voulez pas écrire un Service, et si vous voulez vraiment garder cette logique dans le dépôt lui-même, passez l'autre dépôt comme argument dans cette méthode spécifique.

J'espère que je me suis fait un peu clair. : P

Answer 2

Ils ne devraient pas vraiment s'appeler. Un référentiel est une abstraction des opérations (plus ou moins) atomiques que vous souhaitez effectuer sur votre domaine. Moins ils ont de dépendance, mieux c'est. De manière réaliste, tout consommateur d'un référentiel devrait s'attendre à pouvoir pointer la classe du référentiel dans une base de données et lui faire effectuer les opérations de domaine nécessaires sans beaucoup de configuration. Ils doivent également représenter les agrégats dans votre domaine, c'est-à-dire les points centraux sur lesquels de nombreuses fonctionnalités seront basées. Je me demande pourquoi vous auriez un référentiel d'adresses séparé? Cela ne devrait-il pas faire partie de votre référentiel client?

Answer 3

Cela dépend du type de référentiel (ou du moins des conséquences), mais en général, si vous avez des référentiels de données qui s'appellent, vous allez rencontrer des problèmes avec des choses comme cycliques (repo A -> nécessite B -> nécessite C -. Oops, nécessite A) ou des charges de données récursives (A-> nécessite B & C -> C exige D, E -> .... -> .. ad nauseum). Les tests deviennent également plus difficiles.Par exemple, vous devez charger votre référentiel d'adresses pour exécuter correctement votre référentiel client, car le référentiel client appelle le repo d'adresse. Si vous devez tester le repo client, vous devrez effectuer un chargement db des adresses ou les simuler d'une manière ou d'une autre, et finalement vous ne pourrez pas charger et tester un seul référentiel système sans les charger tous. Ces dépendances sont également insidieuses car elles ne sont souvent pas claires - en général, vous avez affaire à un référentiel en tant qu'abstraction de données - si vous devez être conscient de la façon dont elles dépendent l'une de l'autre, vous pouvez Ne les utilisez pas comme une abstraction, mais vous devez gérer le processus de chargement lorsque vous voulez les utiliser.