Question,
After going through the book and the sample app I am trying to find the best way to impl an object as both a parent and a child. For example my Location object can be a parent and a child of other Locations.
In the database this is represented by a Locations and a RelatedLocations table that manages the relationships between the objects.
In first looking at it I was assuming that I would need a BusinessListBase class to manage the collection of relationships but now I am not so certain...any suggestions?
Thanks
Although I've never used it, the Switchable type is designed to be both a parent and a child. It's described in chapter 7.
Now, people will say, and the book says that using switchable objects is usually a sign of bad design, but there are times when it makes sense. I've never seen an example of when it would make sense, but apparently there are.
There's nothing wrong, and usually there's good reasons to have two objects (or more). That is, you can have a LocationRoot object and a LocationChild object. They may share the same data, but they're used differently, so that's a good reason for two objects.
Regards,
Mike
Mike,
Thanks for the reply. Yes I saw that discussion in Chap. 7 about switchable objects (and the note about it being bad design). I guess I just wasnt clear on how it would apply in this case (esp managing relationships between the parent and child).
Your right about using two objects, that would certainly work...
Kind of a yin and a yang situation...
Mark
What about Figure 3-3 on page 120? There is a Parent-Child-Grandchild relationship pictured, and this "ChildParent" class being a child and a parent *at the same time*. I'm facing a situation exactly like this right now, and I'm not sure I can figure out a way around it.
Wes
I think the terminology needs to be cleared up. Instead of parent and child, we should be saying root and child. A root object is just that - it's a root that stands on it's own. A root object can contain children, and those children can contain child objects as well. Like I said, I've never used a Switchable object, but I understand it as it can be a root or a child.
I'm going to guess that if sometimes you need an object to be a root, and sometimes you need it to be a child, you're going to want to have two objects. e.g. CustomerEditableRoot and CustomerEditableChild.
What are your use cases? I think explaining what you need to do would help clear up what types of objects you need.
Regards,
Mike
Let's focus on "those children that can contain child objects as well". To my understanding, they are parents/roots and children, therefore can't be switchable, because switchable objects are parents/roots or children. Is there a standard template for those "ChildParents" available somewhere?
Wes
Wes:
Root and parent are different concepts.
So your middle class in your Root -> Child -> Child hierarchy is still a Parent, but not a Root, i.e. you never start the save/retrieve process at the middle level of this class hierarchy.
So a "switchable" object is one that can act as Root (start the transaction), or as a child in another retrieval/save transaction.
--Bruce
Hope I'm not being confusing with the parent/root thing. "those children that can contain child objects as well" are not root objects. They're parents, but not roots. The paragraph on pg. 120 of the C# book, just above figure 3.3 explains this.
I use the CodeSmith templates, and those cover everything you need. Not sure if other templates are out there or not.
Mike
Copyright (c) Marimer LLC