Les Services et les Dépôts en DDD (C#)

Comment Services et Repositories se rapportent les uns aux autres en DDD? Je veux dire, j'ai lu sur des DDD pour les 2 derniers jours, et partout où je vais, il y a toujours un Service couche et il y a toujours un Repository couche. Comment les différencier ou se compléter les uns les autres?

De ce que j'ai lu, n'est-ce pas le Repository la couche responsable de la délégation des interactions entre l'application et les données?

Alors, quelle est la nécessité pour le Service couche si c'est pour mettre en œuvre les Repository pour interagir avec les données de toute façon, même si le Repository probablement déjà implémente les méthodes nécessaires pour le faire?

J'apprécierais quelques lumières sur le sujet.

P. S. Ne sais pas si cela va aider, mais je travaille avec une ASP.NET MVC 2 application dans laquelle je suis en train de mettre en œuvre le modèle de Référentiel. Je viens de terminer la mise en œuvre de l'Injection de Dépendance motif (pour la première fois)...

Mise à JOUR

Bon, avec donc beaucoup de réponses, je pense que je comprends ce qu'est la différence. Ainsi, à l'examen (corrigez-moi si je me trompe):

  • Un Repository couche interagit avec un objet de la base de données ou de l'ORM, IEmployeeRepository -> Employee.

  • Un Service couche encapsule plus de fonctions complexes sur les objets retournés à partir de Repositories, soit une ou plusieurs.

Donc, puis-je avoir une sous question. Est-il considéré comme une mauvaise pratique pour créer résumé objets à envoyer à mon point de vue? Par exemple, une AEmployee (A pour abstract parce que pour moi I signifie interface) qui contient des propriétés de Employee et X ou X?

En fait, un de plus subquestion. Si un Service couche peut être considéré comme "à l'écoute" pour un demande-t-il besoin d'être mis en œuvre avec une interface?

  • Je crois que les services peuvent regrouper plusieurs référentiels.
  • Il y a une sacrée différence entre le commun populaire et d'utilisation du Référentiel et du Service (l'utilisation trouvés dans de nombreux exemples, & tutoriels) et comment Domain Driven Design définit ces. Je crois qu'il est important de comprendre les différences.
  • est - il devrait y avoir un référentiel par agrégat de la racine, mais un service peut être (et sera) un travail sur plusieurs reposities, rendue possible par le motif d'unité de travail. et en passant, combien de fois puis une question comme cela sera demandé? il ya beaucoup de questions au sujet de ce sur un débordement de pile.
InformationsquelleAutor Gup3rSuR4c | 2010-11-11
  1. 18

    Vrai, un référentiel fonctionne avec des données (ie. SQL, Webservices, etc.) mais c'est le seulement travail. Les opérations CRUD, rien de plus. Il n'y a pas de place pour la procédure stockée en fonction tations de la logique.

    Le service (ou de la couche logique métier) fournit la fonctionnalité. Comment répondant à une demande d'entreprise (ie. calculer le salaire), ce que vous avez à faire.

    Oh, et c'est vraiment une bonne DDD livre:
    http://www.infoq.com/minibooks/domain-driven-design-quickly

    • Avec vous entièrement, sauf pour vous, ne pouvez pas appeler stockées procs. Pourquoi pas si vous pouvez renvoyer des données à partir d'une vue, pourquoi ne pas renvoyer des données à partir d'une procédure stockée?
    • Cela suppose aucune procédure stockée? Si vous avez des procédures stockées où est le code d'appel si pas dans le référentiel? Je ne serais pas d'accord que le modèle de référentiel s'oppose à la logique d'entreprise dans les procédures stockées. Le référentiel est un condensé de tous de la base de données des interactions - les deux CRUD et des procédures stockées.
    • Michael Shimmins: je pense que c'est pas une bonne pratique pour split tations de la logique en morceaux. Si j'ai une couche de gestion, je dois tout mon domaine logique d'accueil de là. Bien sûr, j'ai "intelligents" les procédures stockées trop ie. pour un reporting rapide. Mais sp a rien à voir avec la logique d'entreprise. Leastways en DDD.
    • Gaunt: non. Bien sûr, les procédures stockées sont grands. J'ai dit que d'éviter de la logique métier dans les procédures stockées.
    • "Le service (ou de la couche logique métier) met en œuvre la logique de domaine" - je suis désolé, mais ce n'est pas DDD à tous. C'est un anti-modèle en DDD.
    • Pourquoi pas de la logique métier dans des procédures stockées? Je pense que c'est une contrainte inutile. Un peu de logique métier est beaucoup plus naturellement mis en œuvre dans la base de données. Il ya quelques bonnes raisons pour ne pas utiliser des procédures stockées pour une logique complexe - mais la plupart d'entre eux proviennent de ne pas avoir beaucoup de compétences en SQL dans l'équipe. La logique d'entreprise doit exister dans le domaine du service - mais le dépôt fait partie du domaine service.
    • Je pense que tu parles de l'anémie du modèle de domaine, correct? Le terme "service" est tellement galvaudé que je ne pense pas que n'importe qui peut dire que c'est un modèle ou anti-modèle sans voir exactement comment il est utilisé.
    • Correct. Le terme "Service" n'est pas galvaudé à l'intérieur de Domain Driven Design. C'est pourquoi je dis qu'il ya une distinction importante entre ces termes à l'intérieur de DDD et à l'extérieur de DDD.
    • c'est vrai, je ne suis pas précis, je vais le corriger. Mais dans un premier temps "le service est un point de connexion pour de nombreux objets" et d'autres sont peut-être trop poussiéreux. C'est pourquoi j'ai lié Eric Evan livre (voir url).
    • Gaunt: il y a des exceptions, mais dans la plupart des cas - à mon humble avis, c'est difficile à assurer la cohésion. Les objets de domaine et SQL sp...il semble un moyen dur pour moi:) Avez-vous peut-être des articles/blogposts à ce sujet?
    • pas d'articles désolé - c'est juste une opinion. Je travaille principalement dans les applications web, où à la fin de la journée, la base de données est l'application - une fois la demande de page se termine, c'est tout ce qui reste. Dans ces cas, il est souvent beaucoup mieux à exécuter la logique sur la DB plutôt que de courriers beaucoup de l'état de la base de données pour faire des comparaisons ou des décisions qu'à jeter tout de suite à nouveau millisecondes plus tard. C'est une partie de l'idiome de la prise du traitement de données, plutôt que de prendre les données pour le traitement.
    • est un point de connexion" - C'est une excellente façon d'expliquer un Domaine de Service. C'est un point d'entrée pour les clients. Il prend les Commandes (qui est souvent un DTO, ou en fait un sac de propriétés simples) et les effectue en invoquant les méthodes correctes sur les Entités.
    • Mieux comment? Vous semblent impliquer un meilleur rendement ("courriers beaucoup de l'état"), mais cela semble être une préoccupation qui est souvent hors de propos (je peux tirer de 100k Entités de la DB dans le même laps de temps, il prend le navigateur à télécharger jquery.js). Sprocs, ime, ont tendance à compliquer, ou de rendre pratiquement impossible, pièces de DDD (Événements serait une première mention). De Plus, également ime, mélange de logique entre l'application et la db a une façon exponentielle mauvais effet sur l'effort de maintenance comme la taille de l'application & à la complexité croissante.
    • le droit d'auteur par Eric Evan:)
    • lol, fait sens
    • Comment générales concernant les "externes" des opérations comme "EmailSender" de la classe? Si ce n'est dans l'application de la logique métier, mais vous ne pouvez pas appeler un Fournisseur car, sur le plan grammatical, il serait incorrect. Serait le nom EmailSendingService sens?

    InformationsquelleAutor boj
  2. 24

    Le Service va utiliser un Référentiel pour récupérer une Entité, puis appeler des méthodes sur elle (l'Entité) pour exécuter la Commande/de la tâche.

    • +1: autant d'informations en si peu de mots...
    InformationsquelleAutor quentin-starin
  3. 10

    Comme un exemple concret d'un Panier d'application peuvent avoir les services suivants:

    ShoppingCartService - gère un panier d'éléments à ajouter/supprimer/mettre à jour soutien, etc.

    OrderService - prendre un chariot, la convertit en une commande et gère le processus de paiement etc.

    chacun de ces services doit parler d'une "source de données" pour les opérations CRUD. C'est là que le modèle de Référentiel est très pratique car il fait abstraction du chargement et la sauvegarde des données vers et à partir de la source de données une base de données, des services web ou encore en mémoire cache.

    Lorsque vous souhaitez créer un prototype rapide de votre application sans avoir à traiter avec l'installation de base de données, schéma, des procédures stockées, des autorisations, etc. vous pouvez créer un cache ou faux référentiel dans une affaire de minutes.

    Pour l'exemple au-dessus de votre prototype pourrait commencer avec les éléments suivants:

    • FakeCustomerRepository
    • FakeAddressRepository
    • FakeCartRepository
    • FakeCartLineItemRepository
    • FakeOrderRepository
    • FakeOrderLineItemRepository

    une fois que votre prototype est prêt à passer au niveau suivant, vous pouvez mettre en œuvre ces contre une véritable base de données:

    • SQLCustomerRepository
    • SQLAddressRepository
    • SQLCartRepository
    • SQLCartLineItemRepository
    • SQLOrderRepository
    • SQLOrderLineItemRepository
    • À partir de quelques exemples que j'ai vu il y aurait un Projet.Référentiel de la bibliothèque de la classe et comme un Projet.Classe de Service de la bibliothèque à la maison les classes que vous avez énumérés ci-dessus. En général, je vois un Projet.Modèle de bibliothèque de classes. Où placez-vous les interfaces pour les classes de dépôt dans le cadre du Projet.Modèle?
    • Habituellement, j'ai respository et les modèles de dossier à l'intérieur de mon Projet.Projet de Service. Puis-je avoir /Repository/Interfaces, /Repository/FakeRepository, /Repository/SQLRepository, /Modèles /Service/Interfaces, /Service/[mise en œuvre des classes]. Je n'ai pas l'habitude de partager des dépôts dans l'ensemble des services, parce que mes dépôts sont conçues spécialement pour les modèles au sein de ce service.
    InformationsquelleAutor Todd Smith
  4. 5

    De ce que je me souvienne, le référentiel est le dernier cours avant les données. La classe de service peut agir sur les données extraites du référentiel. Le référentiel est vraiment juste pour obtenir les données à quelqu'un d'autre pour faire le travail. La couche de service peut fournir des choses telles que la logique métier que toutes les données doivent passer à travers. Il pourrait également fournir une traduction entre la logique applicative et la couche de données. Mais encore une fois, c'est exactement ce que je me souviens.

    InformationsquelleAutor Josh
  5. 4

    Il n'y a pas d'or, norme qui définit un service ou un référentiel. Dans mes applications, un référentiel est (comme vous dites) d'une interface dans une base de données. Un service a accès à un référentiel, mais le service expose un sous-ensemble de fonctionnalités à ses consommateurs.

    Penser le référentiel de plus faible niveau. Le référentiel a pour exposer de nombreuses manières d'accéder à la base de données sous-jacente. Un service peut combiner les appels à un référentiel à un autre code qui n'a de sens qu'à un niveau de code (c'est à dire pas dans la base de données), tels que l'accès à d'autres de l'état dans l'application, ou de la validation et de la logique d'entreprise qui ne peuvent pas facilement être appliquée dans une base de données.

    InformationsquelleAutor James Gaunt