Les dépôts DDD en tant que singletons?

Question

Question rapide: Serait-ce une bonne ou une mauvaise idée de mettre en œuvre mes référentiels de styles de conception gérés par des domaines en tant que singletons? Pourquoi?

Ou devrais-je peut-être utiliser un conteneur d'injecteurs de dépendance pour gérer mes référentiels et décider s'il s'agit de singletons ou non?

Je suis toujours en train de lire DDD Quickly et j'aimerais voir de bons exemples de référentiels.

Answer 1

J'ai déjà vu plusieurs façons de le faire.

Le moyen le plus courant consiste à utiliser l'injection de dépendance pour injecter les référentiels dans les objets qui les utilisent. Généralement, ce sont des classes de présentateur ou de contrôleur, mais dans certains cas, le modèle appelle dans le référentiel. Habituellement, il vaut mieux éviter cela. Si vous pouvez utiliser un di-conteneur pour le faire, allez-y.

Vous pouvez également faire en sorte que les référentiels implémentent le motif singleton. J'essaierais d'éviter cela parce que les singletons utilisent généralement des méthodes statiques. Cela peut rendre plus difficile le test du code qui appelle les singletons. Si vous devez faire les choses de cette façon, assurez-vous de séparer le code qui appelle le singleton et utilisez " manual " injection de dépendance pour injecter les singletons dans les classes qui les appellent. Cela élimine certains des couplages étroits que vous auriez autrement.

J'ai vu des exemples où les référentiels ne sont jamais appelés. Lorsque quelqu'un navigue dans le graphe d'objets du modèle et demande un objet non chargé, le modèle déclenche simplement un événement et le référentiel réagit à cet événement. De cette façon, il n'y a aucun appel dans le référentiel et il est complètement découplé du modèle. Je n'ai pas utilisé cette architecture moi-même, mais elle semble très propre.

Answer 2

Utilisez votre conteneur d'injection de dépendance pour décider comment et où les référentiels sont créés.

En utilisant

UserRepository.Instance.Find(userId);

vous créez un obstacle aux tests.

Si vos référentiels sont passés aux services à l'aide de Constructor Injection, vous pouvez également les remplacer facilement par des mocks.

Answer 3

Je ne suis pas sûr de cela et j'ai le même problème. Je pense que vous devriez transformer un référentiel en singleton lorsque les objets avec lesquels il fonctionne sont utilisés souvent. Et qu'il ne devrait pas être transformé en singleton si vous utilisez des objets avec lesquels il fonctionne rarement, car le référentiel prendrait beaucoup de mémoire pour les objets et qu'il serait peut-être appelé une seule fois et jamais plus lors de l'utilisation de l'application. Comme je l'ai dit, il se peut que ce ne soit pas une pensée correcte.

Answer 4

Disons que j'ai un très gros projet et que je veux ajouter un nouveau service, disons que ce serait un représentant du matériel dans mon système. Je veux que ce service soit accessible à travers de nombreuses classes. Je veux être sûr qu'il n'y a qu'une instance de service ou une couche qui contrôle l'accès au service. Injecter ce service dans tout mon système (plus de 200 cours) représenterait beaucoup de travail. Pour moi " Singleton " ou certains " Service Locator " convient bien pour cette tâche.

Answer 5

Autant que je sache, le domaine ne contient qu'une interface de référentiel, ce qui signifie qu'il peut exister de nombreuses implémentations de référentiel pour une seule interface. Ainsi, un référentiel ne peut certainement pas être une classe statique, car vous ne pouvez pas définir de méthodes statiques dans une interface. (Remarque: dans certaines langues, vous pouvez définir des méthodes statiques dans une interface, mais cela n'a pas beaucoup de sens pour moi.)

Les référentiels concernent généralement la synchronisation des entités avec des bases de données, des fichiers, etc., de sorte qu'ils ont des dépendances non stables. Ce qui signifie qu'ils ne peuvent pas être singletons ne peuvent avoir que des dépendances ambiantes. Voici un article à ce sujet. La partie amusante même les auteurs vous disent que vous pouvez utiliser des singletons dans votre domaine.

À ma connaissance, il est beaucoup plus simple de créer un référentiel garantissant que vous n’avez qu’une seule entité au lieu de plusieurs. C’est la responsabilité du référentiel, pas celle de l’entité si vous souhaitez que votre code respecte le principe de responsabilité unique .