views:

211

answers:

4

I'm trying to figure out how to best lay this out. I'll explain what I have now, but I'm wondering if there is a better way to do this.

I have a class Section that has basic properties: Name, Description, et.al. I use a list of Sections for the users to choose from. They can add a Section as many times as they want to a Parent object and any number of Sections.

When they add a Section to the parent, they have to assign what group it belongs to (lets say group1, group2, group3) and in what order it will be displayed. This Group property is not on the table, there is no group needed when I list out the Sections for the user to choose from, it wouldn't make sense. Think of this Section they are adding as a clone with extra properties.

I have another table that has a foreign key to the Parent and to the Section. Many sections can be added to 1 Parent. On this link table is also the Grouping and DisplayOrder columns (as well as a few others) for each section that they add.

So when I create the Parent object and query a collection of its Sections, do I want to try and use the same Section class and add a Grouping property?

 Section 1
 Section 2
 Section 3


Parent 1
     Section 1 - Group = g1, DisplayOrder = 1
     Section 1 - Group = g2, DisplayOrder = 2
     Section 2 - Group = g2, DisplayOrder = 3
     Section 3 - Group = g3, DisplayOrder = 4

Parent 2
     Section 4 - Group = g3, DisplayOrder = 1
     Section 1 - Group = g2, DisplayOrder = 2
     Section 2 - Group = g3, DisplayOrder = 3

Tell me if you have no idea what I'm saying and I'll try to explain it better...or I'll delete it and pretend like I never asked. =P

A: 

I would add the group property. A null value would be appropriate for a section that had not been assigned to a parent. This is similar to the behavior of Owner in windows forms components.

C. Ross
A: 

I would make group a property of Section. Then you can add properties for group1, group2, etc on Parent using LINQ to query the collection an return only those in each group (if you need to be able to do that).

jhunter
+1  A: 

It sounds like the group isn't an intrinsic property of a section. It's only meaningful when relating sections to parents. Given this, I wouldn't add a group property. Maybe make a section container class that exposes the group:

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

or make grouping a property of parent, e.g.

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

You may need more than one section grouping strategy, after all, so it's best not to couple your section design to the types of collection it can be contained within.

Andy
I ultimately used this solution, more specifically the "make grouping a property of parent."
Dustin Brooks
+1  A: 

When possible in object hierarchies, you want to avoid child to parent links. It makes for very tight coupling and awkward relationships.

Assuming I understand your problem, I would create a Group object to insert between the parents and the sections. A parent would have a list of groups, and each group would have a list of sections.

Edit in response to DisplayOrder:

Display order is actually a property of the parent, not the sections. A parent contains a list of sections, and that list has a particular order associated with it.

17 of 26
I like this solution. How would I handle a DisplayOrder (I updated the above). Each section added also has a DisplayOrder (Order they will be displayed on the screen) Will I need two linking tables? Parent > Group > GroupSection > Section with Group section knowing the DisplayOrder?
Dustin Brooks