Les référentiels devraient-ils à la fois charger et sauvegarder des entités?

Question

Dans ma conception, j'ai des classes de Repository qui obtiennent des Entités de la base de données (Comment ça fait que cela n'a pas d'importance). Mais pour sauvegarder les entités dans la base de données, est-ce logique de faire en sorte que le dépôt le fasse aussi? Ou est-il plus logique de créer une autre classe (comme UnitOfWork), et de lui donner la responsabilité de sauvegarder des choses en lui faisant accepter des Entités, et en appelant le save() pour lui dire d'aller de l'avant et de faire sa magie?

Answer 1

Dans DDD, les dépôts sont définitivement où ALL choses liées à la persistance devrait résider.

Si vous avez sauvegardé et chargé à partir de la base de données encapsulée dans plusieurs classes, le code lié à la base de données sera réparti sur un trop grand nombre d'endroits dans votre base de code - rendant ainsi la maintenance nettement plus difficile. De plus, il y a de fortes chances que les lecteurs ultérieurs de ce code ne le comprennent pas à première vue, car une telle conception n'adhère pas aux quasi-standards que la plupart des développeurs s'attendent à trouver.

Bien sûr, vous pouvez avoir des classes Reader/Writer-helper séparées, si cela est approprié dans votre projet. Mais vu du Business Layer, la seule passerelle vers la persistance devrait être le référentiel ...

HTH!
Thomas

Answer 2

Je donnerais au référentiel la responsabilité globale de l'encapsulation de tous les aspects de la charge et de l'enregistrement. Cela garantit que les problèmes délicats tels que la gestion des conflits entre les lecteurs et les écritures ont une place à gérer.

Le référentiel peut très bien utiliser votre classe UnitOfWork et peut nécessiter l'affichage de méthodes BeginUow et Commit.

Answer 3

Fowler says que api de dépôt doit imiter collection:

Un dépôt intermédiaire entre les couches de domaine et de mappage de données, agissant comme une collection d'objets de domaine en mémoire .