Question de conception d'architecture d'objet

Question

Je suis en train de chercher comment organiser au mieux cela. Je vais expliquer ce que j'ai maintenant, mais je me demande s'il existe une meilleure façon de le faire.

J'ai une classe Section qui a des propriétés de base : Nom, Description, etc. J'utilise une liste de Sections pour que les utilisateurs puissent en choisir. Ils peuvent ajouter une Section autant de fois qu'ils le souhaitent à un objet Parent et un nombre quelconque de Sections.

Lorsqu'ils ajoutent une Section au parent, ils doivent lui assigner à quel groupe elle appartient (disons groupe1, groupe2, groupe3) et dans quel ordre elle sera affichée. Cette propriété de Groupe n'apparaît pas dans le tableau, aucun groupe n'est nécessaire lorsque j'énumère les Sections disponibles pour l'utilisateur, cela n'aurait pas de sens. Pensez à cette Section qu'ils ajoutent comme un clone avec des propriétés supplémentaires.

J'ai une autre table qui a une clé étrangère vers le Parent et vers la Section. Plusieurs sections peuvent être ajoutées à un Parent. Sur cette table de liaison, se trouvent également les colonnes Groupement et Ordre d'affichage (ainsi que quelques autres) pour chaque section ajoutée.

Donc, lorsque je crée l'objet Parent et interroge une collection de ses Sections, dois-je essayer d'utiliser la même classe Section et ajouter une propriété de Groupement ?

 Section 1
 Section 2
 Section 3

Parent 1
     Section 1 - Groupe = g1, Ordre d'affichage = 1
     Section 1 - Groupe = g2, Ordre d'affichage = 2
     Section 2 - Groupe = g2, Ordre d'affichage = 3
     Section 3 - Groupe = g3, Ordre d'affichage = 4

Parent 2
     Section 4 - Groupe = g3, Ordre d'affichage = 1
     Section 1 - Groupe = g2, Ordre d'affichage = 2
     Section 2 - Groupe = g3, Ordre d'affichage = 3

Dites-moi si vous ne comprenez pas ce que je dis et j'essaierai d'expliquer mieux...ou je le supprimerai et ferai semblant de ne jamais avoir posé la question. =P

Answer 1

Il semble que le groupe n'est pas une propriété intrinsèque d'une section. C'est seulement significatif lorsqu'on relie des sections aux parents. Vu cela, je n'ajouterais pas une propriété de groupe. Peut-être créer une classe de conteneur de section qui expose le groupe:

interface IGroupedSection
{
    ISection Section { get; }
    string Group { get; }
}

ou faire du regroupement une propriété du parent, par exemple.

interface IParent
{
     void AddSection(string group, ISection section);
     IEnumerable GetSectionsInGroup(string group);
}

Il est possible que vous ayez besoin de plus d'une stratégie de regroupement de sections, après tout, donc il est préférable de ne pas lier votre conception de section aux types de collection dans lesquels elle peut être contenue.

Answer 2

Lorsque cela est possible dans les hiérarchies d'objets, vous voulez éviter les liens entre enfants et parents. Cela crée un couplage très serré et des relations maladroites.

Si je comprends bien votre problème, je créerais un objet Groupe à insérer entre les parents et les sections. Un parent aurait une liste de groupes, et chaque groupe aurait une liste de sections.

Édition en réponse à DisplayOrder :

L'ordre d'affichage est en fait une propriété du parent, pas des sections. Un parent contient une liste de sections, et cette liste est associée à un ordre particulier.

Answer 3

Je ajouterais la propriété de groupe. Une valeur nulle serait appropriée pour une section qui n'a pas été assignée à un parent. C'est similaire au comportement de Propriétaire dans les composants de formulaire Windows.

Answer 4

Je ferais du groupe une propriété de Section. Ensuite, vous pouvez ajouter des propriétés pour le groupe1, groupe2, etc. sur Parent en utilisant LINQ pour interroger la collection et ne retourner que ceux de chaque groupe (si vous avez besoin de le faire).