DAO, dépôts et Services en DDD

après avoir lu plusieurs articles, je commence à comprendre la différence entre le DAO et les dépôts, mais j'ai du mal à comprendre la différence entre les dépôts et les Services.

Pour la mise en court termes, dans le paradigme OO:

  • DAO : classe qui contient le CRUD operations de base pour une classe d'entité. Il a le code nécessaire pour obtenir ou récupérer les choses du système de stockage persistant sous-jacent. En général, les méthodes reçoivent les entités d'objet comme paramètres, sauf dans la méthode retrieve où l'utilisation d'un type D'identificateur est valide.

  • Référentiels : Dans un niveau d'abstraction supérieur.. comme généralement j'ai Lu est une sorte d'endroit où mettre le code qui traitent des opérations sur les objets agrégés (objets qui ont des objets enfant). Il utilise le DAO s pour récupérer des objets à partir de la base de données, et à la fin il expose une interface dans le domaine "business" langue. (Mais encore une fois, je pense qu'il est très valide d'utiliser des types de données d'ids). Exemple: un addSomething très simple où something est un objet enfant du parent dont les instances, btw, sont gérées dans leur ensemble par le référentiel.

  • Services : là encore, c'est dans un niveau plus élevé d'abstraction. À mon humble point de vue ils sont un bon endroit pour connecter deux classes qui ne partagent pas la relation parent-enfant, mais est aussi loin (en termes d'abstraction) que le référentiel. Exemple: la méthode transferCash entre deux bank accounts .

donc, ce sont mes lectures sur, mais je demande ici les pensées ci-dessus sont justes ou non. Ou comment je devrais penser. Ou quelque chose qui m'indique de vraiment comprendre la différence de tous ces concepts.

Quelques sources:

29
demandé sur Community 2013-11-12 21:22:06
la source

3 ответов

les dépôts sont - comme vous dites-une abstraction. Ils proviennent du de Martin Fowler "Object Query Pattern . Les deux référentiels et les DTO peuvent simplifier la persistance de la base de données en cartographiant les données persistantes à une collection équivalente d'objets d'entité. Cependant, les dépôts sont plus grossiers que les OAD, car ils permettent de contrôler une "racine agrégée 151970920" (AG) qui cache souvent beaucoup d'état interne au client. DAO, d'un autre côté, peut être aussi précis que d'être dédié à un seul objet d'entité. Pour les deux dépôts et DAOs, il est courant d'utiliser Hibernate ou D'autres cadres de cartographie objet/relationnelle (ORM) au lieu d'écrire votre propre implémentation.

typiquement, les services peuvent résider dans une couche de Service et peuvent agir à la fois comme une façade de fonctionnalité, couche anti-corruption et coordinateur pour la mise en cache et la transaction. Ils sont souvent un bon endroit pour effectuer l'enregistrement. Service à grains grossiers et orientés usecase, p.ex. Service.updateCustomerAdress() ou Service.sendOrder() . Les dépôts peuvent être trop fins pour être consommés par les clients, par exemple Customer.add(…) , Order.modify(…) .

les dépôts et les OAD ont le même but - persister les données en permanence. D'un autre côté, les Services devraient ignorer la persistance et ne pas avoir connaissance de votre base de données. Ils travaillent généralement en étroite collaboration avec les services de domaine, les dépôts, le noyau du domaine.

21
répondu Magnus Backeus 2017-05-23 15:02:44
la source

Référentiels sont des interfaces de stockage et de récupération "151910920 de la" somme des Racines (AR) , et non pas des Entités uniques. Vous avez un dépôt pour chaque AR de votre modèle de domaine.

comme dans de Fowler" motif de dépôt , les dépôts agissent comme une collection d'objets en mémoire et c'est l'une des principales différences les comparant aux Aad.

les interfaces de stockage sont un moyen Le client du modèle de domaine (et font donc partie du modèle de domaine) pour commencer à travailler avec le modèle de domaine. Les clients sont destinés à obtenir une instance AR à partir d'un dépôt, appeler une méthode sur elle, qui modifie habituellement son état interne, puis la stocker de nouveau dans le dépôt.

13
répondu Enrico Sanguin 2017-05-23 15:17:55
la source

Je ne sais même pas ce qu'est" DAO". Les dépôts sont une abstraction pour charger des entités. Vous devriez être capable d'obtenir une entité et D'en sauver une, c'est tout. Aucune interrogation. Si vous voulez interroger certaines données, écrivez une requête (peut-être même dans une méthode D'action MVC, ou avec le plus simple des abstractions simples permettant à un certain SQL d'être exécuté et à certains DTOs retournés qui peuvent être rendus directement dans le HTML).

Services d'autre part sont délicats. Pour commencer, le terme est surcharger. Les " services d'Application "tels que définis par le DDD book d'Eric Evans existent parce que les objets dans le modèle de domaine ne sont pas autorisés à accéder à des préoccupations d'infrastructure comme les bases de données, la messagerie, la mise en cache, etc. Ils ont besoin que tout cela soit fait pour eux et leur soit remis sur une assiette, et les services D'Application font exactement cela. Les services d'Application, pour leur part ne contiennent pas de logique . Je ne m'attendais pas à voir ICustomerService.ChangeAddress() faire autre chose que:

  1. Charge le Client de l'entité.
  2. Appel Customer.ChangeAddress(newAddress) <- c'encapsule la logique de domaine
  3. Enregistrer le client.
  4. peut-être publier certains événements.

si vous avez un service qui charge un client, définit sa propriété D'adresse et l'enregistre, alors ce service est en fait un Script de Transaction et le client est un DTO. Ce qui signifie que vous avez certainement une abstraction qui fuit et susceptibles d'avoir un faible modèle de domaine. Les objets Domain model ne doivent pas avoir de setters publics, et lorsque DDD est combiné avec CQRS, votre modèle de domaine peut ne pas avoir d'État public au-delà des valeurs de l'ID de l'entité principale.

2
répondu Neil Barnwell 2013-11-14 04:15:58
la source

Autres questions sur