DDD: Les référentiels sont des collections d'objets en mémoire?

Question

J'ai remarqué Repository est généralement mis en œuvre dans l'une des manières suivantes:

Méthode 1

void Add(object obj); 
void Remove(object obj); 
object GetBy(int id); 

Méthode 2

void Save(object obj);  // Used both for Insert and Update scenarios 
void Remove(object obj); 
object GetBy(int id); 

Méthode 1 a la sémantique de collecte (qui est comment les référentiels sont définis). Nous pouvons obtenir un objet d'un dépôt et le modifier. Mais nous ne disons pas à la collection de le mettre à jour. L'implémentation d'un référentiel de cette manière nécessite un autre mécanisme pour conserver les modifications apportées à un objet en mémoire. Pour autant que je sache, cela est fait en utilisant Unité de travail. Cependant, certains affirment que l'UoW n'est nécessaire que lorsque vous avez besoin du contrôle des transactions dans votre système.

La méthode 2 élimine le besoin d'avoir des UOW. Vous pouvez appeler la méthode Save() et elle détermine si l'objet est nouveau et doit être inséré ou modifié et doit être mis à jour. Il utilise ensuite les mappeurs de données pour conserver les modifications apportées à la base de données. Alors que cela rend la vie beaucoup plus facile, un référentiel modélisé n'a pas de sémantique de collection. Ce modèle a une sémantique DAO.

Je suis vraiment confus à ce sujet. Si les dépôts imitent la collection d'objets en mémoire, nous devrions les modéliser selon la méthode 1.

Que pensez-vous de cela?

Mosh

Answer 1

J'ai personnellement pas de problème avec l'unité de modèle de travail étant une partie de la solution. Évidemment, vous en avez seulement besoin pour le CUD dans CRUD. Le fait que vous implémentiez un pattern UoW, cependant, ne fait que dicter que vous avez un ensemble d'opérations qui doivent être traitées en batch. C'est légèrement différent de dire que a besoin de pour faire partie d'une transaction. Si vous analysez suffisamment vos référentiels, votre implémentation peut être indépendante du mécanisme de support que vous utilisez (base de données, XML, etc.)

En ce qui concerne la question spécifique, je pense que la différence entre la méthode un et la méthode deux est triviale, si pour la seule raison que la plupart des instances de la méthode deux contiennent une vérification pour voir si l'identificateur est défini. Si défini, traiter comme mise à jour, sinon traiter comme insert. Cette logique est souvent intégrée dans le référentiel et est plus pour simplifier l'interface exposée, à mon avis. Le but du dépôt est de courtier des objets entre un consommateur et une source de données et de supprimer avoir à connaître directement la source de données. Je vais avec la méthode deux, parce que je fais confiance à la logique simple de la détection d'un identifiant que d'avoir à compter sur les états d'objet de suivi partout dans l'application.

Le fait que la terminologie de l'utilisation du référentiel soit si similaire à la fois à l'accès aux données et aux collections d'objets prête à confusion. Je les traite comme leur propre citoyen de première classe et fais ce qu'il y a de mieux pour le domaine. ;-)

Answer 2

Peut-être que vous voulez avoir:

T Persist(T entityToPersist); 
void Remove(T entityToRemove); 

« persist » étant le même que « Enregistrer ou mise à jour » ou « Ajouter ou mettre à jour » - à savoir. le Repo encapsule la création de nouvelles identités (le db peut le faire) mais renvoie toujours la nouvelle instance avec la référence d'identité.