2009-03-25 9 views
3

Ich bin sehr neu zu DDD. Meine SQL-Tabelle enthält eine Liste von Stilen, jeder Stil hat Farben und Größen. Jetzt arbeite ich an einer Anwendung, wo der Benutzer drei Dropdown-Listen sehen kann, eine für Stil, eine für die Farbe und eine für die Größe. Nun werden diese Dropdown-Listen zunächst mit den eindeutigen Werten geladen. Der Benutzer kann dann einen Stil auswählen, und das System kann dann alle Farben/Größen für diesen ausgewählten Stil finden. Der Benutzer kann das gleiche mit der Farbe tun und es werden die Stile geladen, die der ausgewählten Farbe und den Größen entsprechen. Du hast die Idee.DDD/Repository

Dies sind meine Grundanforderungen. Jetzt dachte ich darüber nach, ein Repository für die Stile zu erstellen (StyleRepository) und alle Stile laden zu lassen und bei Bedarf die Kindfarben und Kindgrößen zu laden.

Wie in meiner App beschrieben, muss ich aber auch die verschiedenen Farben oder Größen laden. Ist es nun empfehlenswert, stattdessen drei Repositories zu erstellen, StyleRepository, ColorRepository, SizeRepository oder würde ich ein komplett anderes Repository erstellen?

Wie gesagt, ich bin ziemlich neu und würde Ihre Vorschläge zu schätzen wissen.

Danke

Antwort

3

Der Stil scheint Ihr Stammobjekt zu sein. Dafür bauen Sie Ihr Repository herum.

Da jeder Stil eine bestimmte Teilmenge von Farben und Größen hat, die für diesen Stil zulässig sind, sollte jeder Stil eine Liste mit Farben und Stilen enthalten.

Ihr Repository wird dann eine FindAll() -Methode haben, um alle Stile zurückzugeben. Jeder Style verfügt über eine eigene Liste mit Farben und Größen, sodass Sie das Repository nicht erneut aufrufen müssen, um diese zu erhalten. Wenn der Benutzer einen bestimmten Stil aus einem Dropdown-Menü auswählt (hoffentlich haben Sie das Style-Objekt gebunden), können Sie einfach die Liste der Farben und Größen aus dem ausgewählten Objekt abrufen und die anderen Dropdown-Listen füllen.

Wenn ein Benutzer einen bestimmten Stil, Farbe und Größe auswählt, würde ich annehmen, dass er in einer separaten Klasse wie einer SelectedStyle-Klasse gespeichert wird, die nur eine Color- und Size-Eigenschaft enthält.

public class SelectedStyle 
{ 
    public Color Color { get; set;} 
    public Size Size { get; set;} 
} 
+0

Danke Chris. Würde ich auch eine FindAllColors() oder FindAllSizes() haben? Bitte beachten Sie, dass ich auch alle verschiedenen Farben und Größen sehen kann und wenn ich meine Farbe in der Dropdown-Liste auswähle, dann sollte ich * alle * Stile und * alle * Größen für die gegebene Farbe sehen. Macht Sinn? – vikasde

+0

Eine wirklich agile Frage ... die Anforderungen ändern sich ständig. Ich würde jetzt sagen müssen, dass Sie überhaupt kein Repository benötigen. Sie benötigen etwas anderes, etwa ein Präsentationsmodell, da Ihre Logik darauf basiert, Listen basierend auf der Auswahl einer anderen Liste anzuzeigen. –

+0

hm .... Ich war ziemlich sicher, dass ich ein Repository brauche. Ein Repository auf höherer Ebene würde es nicht lösen? So etwas wie ein SKU-Repository? – vikasde

0

Wie Farben in Ihrem Fall sind tatsächlich von Arten verwendet Farben, nicht nur abstrakte Farbliste (wie in der Malerei-Anwendung), würde ich gehen mit StyleRepository und addeed Verfahren wie GetAllUsedColors().

+0

Vielen Dank für Ihren Kommentar. Würde ich dann Methoden wie GetColorsByStyle, GetSizesByColor usw. hinzufügen? Würde die Color-Eigenschaft in der lets sagen, dass meine Style-Klasse eine Liste von Farbe oder nur eine Zeichenfolge ist? Tut mir leid, die Fragen klingen einfach :( – vikasde

+0

Als allgemeine Regel sollten Sie "Value" -Objekte (dh Farbe, Geld) zu primitiven Typen (dh String, Dezimal) bevorzugen. – alex

+0

OK, aber wenn meine Style-Klasse wie folgt aussieht: Klasse Stil { .... public virtual Farbe {get; set;} .... } ist die Farbe Eigenschaft sollte ein Array sein – vikasde