DDD principlers et la conception du projet ASP.NET MVC

voix
5

Deux questions de partie

J'ai un agrégat de produit qui a;

Prix ​​PackagingOptions etc descriptions de produits images de produits

J'ai modélisé un référentiel de produits et ne pas créer des référentiels individuels pour l'une des classes d'enfants. Toutes les opérations de db sont traitées par dépôt de produits.

correctement jusqu'à ce que je comprends le concept DDD? Parfois, la question vient à l'esprit que d'avoir un référentiel pour permet de dire que les options d'emballage pourrait rendre ma vie plus facile en allant chercher directement une option d'emballage de la DB en utilisant son ID au lieu de demander le dépôt de produit à trouver dans sa collection de PackagingOptions et donner pour moi ..

Deuxième partie gère la modification de créer des opérations en utilisant le travail de cadre ASP.MVC

J'essaie actuellement de gérer tous les supprimer modifier add de ces collections enfants du produit par contrôleur de produit (son droit?).

Un défi que je suis maintenant face à est;

Si je modifier une option d'emballage spécifique du produit par

mon_domaine / product / editpackagingoption / 10

J'ai accès à l'identifiant de l'option d'emballage

Mais je n'ai pas l'ID du produit en lui-même et cela me force à écrire une requête pour trouver d'abord le produit qui a cette option d'emballage spécifique, modifier ce produit et l'option d'emballage revelant. Je peux le faire que toutes les options d'emballage ont leur carte d'identité unique, mais ce manquerais si j'ai collections qui n'ont pas ID unique.

Cela se sent très mal ..

L'option suivante je pensais envoie les deux ID d'options et de produits d'emballage sur l'URL comme;

mon_domaine / product / editpackagingoption / 3/10

Mais je ne suis pas sûr que ce soit une bonne conception soit.

Donc, je suis à un point que je suis un peu confus. peut-être avoir des malentendus fondamentaux autour de tout cela ...

Je vous serais reconnaissant si vous portez la longue question et aider à me mettre ensemble. Merci!

Créé 27/08/2009 à 00:32
source utilisateur
Dans d'autres langues...                            


2 réponses

voix
3

Dans mon esprit, c'est une de ces choses boueuses qui Pops en DDD.

Dans le code, je traite une racine globale comme un conteneur pour les « relations » et il a des objets d'entité qui ne peut pas exister sans la racine globale.

Par exemple, prenons le Client-> Order-> LineItem-> Exemple de produit qui a été battu à mort maintenant. La racine globale comme je l'ai affiché est client dans ce scénario. Cela étant dit, vous ne voulez pas toujours se rendre à l'ordre par le client. Vous pouvez trouver des commandes à une date précise.

Tournant sur son côté, vous aussi auriez pas un client qui ne dispose pas d'un ordre. Les deux sont dans une relation quelque peu symbiotique si on est pas la racine globale de l'autre.

Le point est que vous ne voulez pas avoir à charger un client par le biais d'une commande, mais vous ne voulez pas nécessairement charger une commande par le client soit.

À partir de l'ordre, cependant, il est peu probable que vous voudriez récupérer juste un LineItem et vous êtes certainement pas à les créer w / o un ordre. À cette fin, l'Ordre sert de porte d'entrée LineItems. LineItems aurait pas besoin de leur propre contrôleur ou dépôt. Ils existent seulement dans l'Ordre lui-même et, en tant que tels, font partie de l'ordre (dans ce cas, l'ordre devient la racine globale) et sont gérées par l'Ordre entité.

Mais, un LineItem aurait probablement une relation avec un produit au sein du système. Les produits auraient leurs propres contrôleurs, dépôts, etc, car ils peuvent exister en dehors de la racine globale.

En résumé à mes divagations, je tends à regarder la façon suivante: si une entité peut exister par lui-même, il devrait avoir un contrôleur. Les entités qui ne peuvent exister sur leur propre (LineItems dans ce cas) ne devraient être gérés par leur contenant uniquement (racine globale).

Est-ce que certains puristes DDD s'il vous plaît me corriger si / où je me trompe?

Quant à la deuxième partie de votre question, je aurais besoin plus de détails sur la façon dont vous envisagez ces entités de travail. Avec ce que vous avez mis ici, j'imagine que PackagingOptions sont liés à un produit et feraient partie d'une racine globale du produit. Maintenant, ce qui implique que vous les modifiez peut se poser la question de ce que c'est une table de consultation dans le système ou sont-ils une compensation des valeurs et, en tant que tels, devraient être traités comme des objets de valeur?

Créé 27/08/2009 à 01:33
source utilisateur

voix
1

Kaivalya,

En ce qui concerne votre dernier commentaire (http apatride):

Ça dépend du contexte. Avant d'entrer dans les détails, je dois vous dire un principe de base sur les agrégats:

Les agrégats définissent un groupe d'objets connexes qui doivent être traités comme une seule unité à des fins de changement de données.

Cela est extrêmement important. Le but d'avoir des agrégats est de faire respecter invariants. Par exemple, vous pouvez avoir une politique comme « Un ordre ne peut pas dépasser 500 $ ». Ensuite, pour appliquer cette politique, vous mettre de l'ordre et OrderItem ensemble dans l'ordre Aggregate. De cette façon, chaque fois que vous ajoutez une nouvelle OrderItem, il convient d'ajouter via l'objet de la commande. Là-bas, vous pouvez vérifier le prix total et assurez-vous qu'il ne dépasse pas 500 $. Si vous ne disposez pas de ces invariants dans votre domaine, alors il n'y a pas de point de chargement de tous ces objets ensemble.

Maintenant, pour revenir à votre commentaire:

Si vous avez invariants qui devrait être appliquée, alors il est normal de charger l'agrégat entier, même si elle peut avoir certains frais généraux. Oui, HTTP est apatride et que vous chargez votre ensemble tout simplement pour modifier l'un de ses objets enfants, puis jetez-le. C'est bon. Ce qui est important est le plus ici que vous imposez vos invariants. C'est ce que DDD est pour.

Le but de DDD est de capturer toutes les logiques d'entreprise dans votre domaine. Vous pourriez certainement obtenir une meilleure performance si vous ne deviez pas charger l'agrégat entier, mais comment voulez-vous appliquer votre invariants? Vous auriez très probablement le faire dans votre procédure stockée. Oui, cela fonctionne, et il est rapide, mais face à des logiques d'affaires dans les procédures stockées lors de l'entretien est un cauchemar. Voilà pourquoi DDD a évolué. Ainsi, vous pouvez modéliser vos besoins d'affaires en utilisant les langues / outils orientés objet, de sorte qu'ils sont plus faciles à comprendre et à modifier.

Rappelez-vous, DDD est une bonne approche mais pas pour tous les types de projets. Si vous avez affaire à un projet dans lequel il y a beaucoup de logiques d'affaires et les chances de les changer en raison de la nature d'une entreprise est élevé, alors vous devriez utiliser DDD. Toutefois, si votre projet est plus d'un « lu quelque chose / écrire quelque chose » sans beaucoup de logique métier en jeu, en utilisant DDD est un mal de tête. Vous pouvez simplement utiliser LINQ to SQL (ou SqlDataAdapters) et envoyer vos objets à vos vues. Vous ne devez même pas à se soucier de trouver des entités, des objets de valeur, des agrégats, Référentiels, etc.

J'espère que cela t'aides,

mosh

Créé 06/04/2010 à 08:58
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more