Devrais-je toujours suivre les services lorsque j'essaie de suivre DDD?
ou puis-je utiliser un référentiel directement pour obtenir un objet de domaine?
3 Réponses :
Personnellement, je n'aime pas voir des référentiels dans des contrôleurs ou dans la couche de présentation en général. Mais je l'ai vu plusieurs fois et il n'y a rien de mal dans le contexte de DDD.
Je pense que la réponse est que cela dépend de la taille de votre projet. Une couche de service est plus souvent trouvée dans des projets plus complexes. ATTENDU QUE les sites Web MVC plus simples, par exemple, utilisent directement des référentiels.
"Je n'aime pas voir des référentiels dans des contrôleurs" => Pouvez-vous élaborer pourquoi et quelle couche intermédiaire vous ajouterait entre le contrôleur et le référentiel?
Les contrôleurs ont tendance à être ballés très rapidement. L'une des raisons en est que les Devs finissent par coller la logique commerciale dans leurs contrôleurs. La logique des entreprises ne devrait vivre que dans la couche de domaine principalement, puis dans la couche de service - pas dans le contrôleur et non dans le référentiel. En utilisant un service (Application) dans votre contrôleur, vous évitez cela. Donc, par exemple, vous appelleriez ComptableVice.GettuserByEmail (email) ou catalogueservices.getProDuckviewModel. Votre contrôleur reste agréable et maigre et votre service de candidature se coordonne à diverses référentielles.
Juste parce que vous obtenez un objet d'un référentiel ne signifie pas que vous traitez dans la logique des affaires. C'est à propos de Obtenir l'objet sur de la couche de domaine à utiliser dans une autre couche. Et je ne peux pas voir comment une seule ligne USEREREPOSITORY.GETTUserByEmail (e-mail) Borne le contrôleur plus que comptableVice.GettuserByEmail (email).
Si vous me dites que votre service transforme l'objet de domaine dans un objet ViewModel, il est peut-être aussi utile, mais cela peut également être effectué dans le contrôleur, et cela ne justifie pas une affirmation aussi définitive comme «Vous ne devez pas utiliser de référentiels. dans les contrôleurs ". En dehors de cela, je ne peux pas voir l'avantage d'une telle couche d'indirection supplémentaire.
Vous avez tourné mon "je n'aime pas voir ..." dans "Vous ne devriez pas utiliser ...". Le premier implique la préférence. Je n'essaie pas de vous dire quoi faire. Votre question donnera toujours une réponse subjective et il n'y a pas de droit ni de mauvais ici. Je dis que quelqu'un qui a traité de très grands contrôleurs, je préfère et recommande de garder autant de code que possible des contrôleurs. J'utilise également le modèle de spécification pour conserver mes requêtes dans ma couche de domaine. Voir Cette réponse pour Suite.
ou puis-je utiliser un référentiel directement pour obtenir un objet de domaine?
Vous pouvez définitivement. C'est précisément l'objectif des référentiels. Je me demande quel type de service vous utiliseriez autrement pour cela (sauf dans le contexte spécifique d'une architecture de SOA ou de service Web).
Ma question (prévue) était si je pouvais contourner les services et obtenir des entités de domaine directement à partir des référentiels (par exemple dans un contrôleur MVC)
Eh bien, je l'ai bien compris et la réponse est oui :) C'est drôle de voir que quelque chose considéré comme parfaitement normal et commun si vous regardez le livre de DDD original et que le mouvement semble maintenant faire peur aux personnes ...
Je n'ai pas peur. Je voulais juste savoir quelle est la meilleure pratique. Le livre a été publié il y a neuf ans et il aurait pu arriver une ou deux choses depuis.
Il n'y a pas de meilleure pratique, seulement des pratiques appropriées dans un contexte donné . Maintenant, les 2 lignes que vous avez écrites ne nous donnent pas une grande partie d'un contexte ...
Après avoir terminé mon premier projet structuré à l'aide des principes DDD: D, j'ai constaté qu'il est utile d'avoir à la fois des services de domaine et des référentiels disponibles pour la couche d'application à consommer.
Point clé: Strong> La couche d'application peut être votre service WCF ou le code de vos services Web si vous utilisez cette architecture. Tout dépend de votre mise en œuvre. S'il convient à votre implémentation, votre couche d'application peut être identique à celle de votre couche de présentation, ce qui dispose donc du code de couche d'application dans votre compositeur ou de votre code de formulaire Web derrière. P> Les référentiels fonctionnent comme des collections en mémoire. Pour la couche d'application, le code devrait ressembler à vous simplement utiliser n'importe quelle vieille collection. P> fonction de services de domaine plus similaire à des processeurs ou d'accessoires à des informations qui ne seront jamais mises à jour, peut-être traitées, mais non mises à jour directement. À la couche d'application, le code doit ressembler à vous simplement utiliser n'importe quel ancien service Web. P> qui étant dit, je vais expliquer davantage avec quelques exemples: p> Dépôt strong> p> Mes référentiels héritent d'une collection générique dactylographiée avec un objet de mise en œuvre que j'ai créé qui encapsule la clé de base de données et le modèle d'entreprise ensemble. En utilisant cette approche, je peux définir un indexeur dans mon interface tel que P> et je peux avoir un getter qui retournera l'objet métier basé sur l'index de la collection sous-jacente et Un setter qui recherchera la clé de données de la collection sous-jacente et enregistrera l'objet à la base de données. Cela rend le code de l'application extrêmement simple, par exemple p> services strong> p> i Utilisez des services pour récupérer des listes d'entités et de valeur Objets que je ne vais pas éditer individuellement et, dans mon cas, ne sont utilisés que comme des sélections ou des valeurs disponibles lorsque vous appelez des méthodes sur la racine globale. En règle générale, je cache ces informations sur le serveur Web. Ce n'est pas la seule utilisation pour un service de domaine, juste mon exemple. Le code de la couche d'application reste toujours relativement simple. P> IBusinessService service = new ImplBusinessService(implementationArgs);
List<BusinessObject> objsToCache = service.GetBusinessObjects();
//cache the objects on the web server.