Liaison DropdownList dans la conception pilotée par domaine

Question

J'ai créé un modèle de domaine et défini des entités, des objets de valeur, des services, etc. Maintenant, ma requête est que j'ai une entité appelée "Company" qui a environ 20+ attributs et je veux lier un contrôle dropdownlist dans une de mes pages qui ne nécessitent que deux attributs, à savoir company.Name, company.Id. Pourquoi devrais-je utiliser une entité aussi lourde ayant plus de 20 attributs pour lier la liste déroulante.

Y a-t-il un moyen de gérer cela en tenant compte des performances?

Merci d'avance.

Answer 1

La question n'est pas très liée à DDD. C'est à propos de la performance.

Comme je le fais - je me fiche de savoir s'il y a 1 ou 20 attributs tant que ces attributs ne proviennent pas de tables séparées. Il n'y a pas de grande différence si select sélectionne 1 ou 20 champs, mais il y a une différence notable si select commence à rejoindre d'autres tables et il y a une différence très visible quand il y a select n+1. Donc, quand je récupère la liste de Company à travers mon ORM afin de créer la liste de sélection, il est assez intelligent pour exécuter sql select seulement sur Company table et charge paresseux d'autres choses si elles sont nécessaires (qui ne sont pas dans ce cas particulier Cas).

Heureusement, je ne développe pas de systèmes qui exigent des performances très élevées, donc je m'en fiche si cela prend 1 ou 20 champs. Si je l'ai fait - je doute que j'utiliserais ORM de toute façon.

---

Pour d'autres mécanismes de persistance, cela peut ne pas poser de problème du tout. Par exemple. - Si vous utilisez la base de données de documents, vous pouvez stocker/extraire l'agrégat entier dans un document, car son schéma est inférieur. La pénalité de performance diminue considérablement.

Answer 2

DDD ne concerne pas les performances. Avec DDD, vous devez utiliser des "agrégats" - ensemble cohérent d'entités connectées. Les agrégats doivent être chargés à partir de la base de données dans la mémoire de l'application. Les requêtes ah-hoc (en fait toutes les requêtes) considérées dans DDD comme "Reporting", et devraient être effectuées par des mécanismes séparés comme les bases de données dénudées.

http://devlicio.us/blogs/casey/archive/2009/02/13/ddd-command-query-separation-as-an-architectural-concept.aspx

c'est des conneries. N'utilisez pas DDD.

Écrire des requêtes quand vous en avez besoin. Utilisez Linq pour composer des requêtes décomposer.

Answer 3

Dans ce scénario, je considérerais soit un service de données de référence renvoyant des représentations allégées du modèle de domaine, soit de préférence (par simplicité) la mise en cache d'un outil. De toute façon, rappelez-vous que c'est seulement quelque chose que vous devriez vraiment vous inquiéter de après vous avez identifié les performances de l'architecture comme étant un problème.

Answer 4

Créez un modèle de clé/valeur générique et exposez une méthode de votre service qui renvoie la liste des noms d'entreprise/d'entreprise. Ceci est similaire aux autres données de type de valeur pour lesquelles vous interrogez votre base de données (code d'état ex/ID d'état).