Object Design Question

malachai24 posted on Wednesday, July 11, 2007

I am designing  some business objects in order to accomodate a tree like hierarchy in a web application. The hierarchy is similar to a treeview. For example, lets say there is 1 root object, Entity1, that is the parent node to Entity2 and Entity3 (all 3 are of the same type, think TreeNode and TreeNodeCollection).

The difference in the hierarchy is that a node that is a child of Entity3 (say Entity4) could also be a node under Entity2 (and could be a child under Entity1, even). No circular references would be allowed, so it would not be possible for say Entity4 to have a child of Entity1

A quick picture (with a few more nodes, notice how Entity4 is in several locations)

Entity1

---Entity2

------Entity4

------Entity5

---Entity3

------Entity4

------Entity6

------Entity7

and possibly

---Entity4

I am concerned that this type of hierarchy is going to be difficult to deal with. I am trying to think of another situation in which this hierarchy is used, but have not come up with any. The folder structure is the closest that I have come up with so far.

The use cases for an Entity/EntityList objects in the hierarchy are:

1. Add an Entity object to the hierarchy.

2. Move an Entity object around in the hierarchy.

3. Delete an Entity object from the hierarchy (and possibly merge children of the Entity to the Entity's parent)

4. Display the entire Entity hierarchy in flattened form.

5. Display the entire Entity hierarchy in hierarchical form.

My thought is to have a ReadOnlyListBase EntityList object that contains the name and id of all the Entities (takes care of use case 4). Then, create the Entity object that would inherit from BusinessBase. Would it make sense to implement use cases 1,2, and 3 using CommandBase objects? Obviously, once either use case 1, 2, or 3 are encountered, the list object(s) would need to be notified of the changes.

I still would need to account for use case 5, so I think I would implement something similar to what is in this post http://forums.lhotka.net/forums/thread/15686.aspx .

Does this seem like a viable solution overall? Am I overcomplicating it?

Thanks for any suggestions,

Mike

hurcane replied on Wednesday, July 11, 2007

I was an initial responder to the thread you referenced. I have dealt with a hierarchy involving "bills of material". A bicycle started out as a bill of material. The same item (e.g. #8x1/2" bolt) may be used in different "subassembly" nodes. Circular references are not allowed.

Entity 1 would be the bicycle. Entity 2 might be the handle bar assembly. Entity 3 might be the rear wheel gear assembly.

In my use case, each instance of an item within a bill of material has unique properties. Within the handle bar assembly, we might use 2 bolts. In the gear assembly, we may only need 1 bolt. Within the hierarchy, they are distinctly different objects. I'm not sure if that is the case with your entities.

We use the "composite" design pattern to represent this hierarchy. It works very well for hierarchies. This is not an easy pattern to implement for the first time. There are several implementation decisions to make that have no "right" answer. One that vexed us for  a while was whether we would include hierarchical methods (e.g. Add/Remove) in the base interface, or just on container object types (i.e. a subassembly).

In our case, we chose to include hierarchical methods on the base interface. This includes a method to get the immediate children of a node. This method is when filling a treeview with the hierarchy, starting from any point in the hierarchy. We also have a method to retrieve the object and *all* of its children in a single collection. This method supports displaying the structure in a flattened form, from any point in the hierarchy. Add/Move/Delete methods also exist.

Your idea of "merging" can be accomplished by moving the children before it is deleted. In your example, if Entity 1 already contained Entity 4, and you deleted Entity 3, would the merge result in two Entity 4 objects under Entity 1?

I'm not sure in an n-level hierarchy pattern is suitable for you. It is doable with CSLA.NET, as we've been using such a design for about 18 months now.