Child - GrandChild Question.

jkellywilkerson posted on Tuesday, August 29, 2006

I am currently implementing my first CSLA project and have an issue I can't get my mind around. I have a Parent BO (Editable Root), a Children BO (Editable Child Collection), a Child BO (Editable Child). If I need the Child BO to be a parent also, do I need to make the child object an Editable/Switchable BO? Or do I just create the GrandChildren BO and GrandChild BO as Editable Child Collection and Editable Child?

Please forgive me, but I am still new to Business Objects and still somewhat trapped by the relational programming mindset.

Thanks in advance.

Kelly.

RockfordLhotka replied on Tuesday, August 29, 2006

If you really have a child that sometimes is a child and sometimes is a root, then switchable is the answer.

However, it is almost always the case that switchable objects indicate a data-centric design, and you are probably better off rethinking your design along behavioral or responsibility-driven lines. Your post doesn't provide enough detail to give you guidance in that regard.

jkellywilkerson replied on Tuesday, August 29, 2006

Thanks for the reply Rocky. I have done a little digging in the previous posts looking at "grandchildren" specific posts, but I can not find anything related to the switchable object. My initial guess was that, if a child was also a parent, it must be a switchable object.

For instance, I have the following object hierarchy:

Group (BusinessBase - Editable Root)

-- Participants (BusinessListBase - Editable Child Collection)

-- Participant (BusinessBase - Editable Child)

-- -- Dependents (BusinessListBase - Editable Child Collection)

-- -- Dependent (BusinessBase - Editable Child)

In this scenario, does the Participant BO have to be switchable? Is this type of setup only for Master/Detail forms display? I am not completely sure that I want to go down this path, just because of the amount of data that will be required for some Group BO's.

I am more inclined to make all three BO's Editable Root objects and use the ID fields from the respective ancestor when creating the child; then using ReadOnlyList and ReadOnlyInfo objects to provide general information for linking.

Does that sound better?

Thanks again,

Kelly.

ajj3085 replied on Tuesday, August 29, 2006

Hi Kelly,

I'd think that Participant isn't supposed to be a child at all. Particpant would be for editing the particpant, which I assume can be done independantly of the editing of the Group? Most likely Particpant would become ParticipantInfo, a read only object who's presense in the list indicates they are a member of the group, but nothing more. The participants class would likely become GroupParticipants.. and it would manage the relationship between a group and participant.

Again, a Dependant would likely be its own root object; Dependants would manage the relationship between the dependant and particpant.

Make sense?
Andy

RockfordLhotka replied on Tuesday, August 29, 2006

"Parent" and "root" are not the same thing. A "root" object is directly persistable, while a "parent" object has child objects. So a root might or might not be a parent, and a parent might or might not be a root. If a parent is not a root, then it is also a child.

Switchable is a stereotype that can be a root or child. Whether it is also a parent or not doesn't matter - the stereotype says that the object can be instantiated as a root (handling its own persistence) or a child (its parent handles its persistence).

jkellywilkerson replied on Tuesday, August 29, 2006

Thanks Rocky,

This new idea of Business Objects is so new to me that it's like a dense fog consuming me. It's a bit overwhelming to make the transition from old-school data-driven relational development to object-oriented functional development.

From what I have been able to glean from the book (C# 2005 version) and the forum so far, this appears to be what I've need for a long time.

I originally purchased the VB5 BO book when it first came out, but due to time pressures, was never really able get in depth with it (much to my demise). Now I have come to my senses.

Thanks for a great book and framework. It will just take me a little while to get up to speed.

Kelly.

jkellywilkerson replied on Tuesday, August 29, 2006

Thanks Andy,

It makes perfect sense. I was a bit worried about having such a deep hierarchy because I could potentially have 50,000 Groups and each Group could potentially have 1,000 to 50,000 Participants, etc. That does not even touch on the other issues such as the Products available to a Group and the Products that each Participant enrolls in. My intitial thoughts were that the system is going to be so slow that it's not even usable.

So do I assume correctly that an Editable Root Collection - Editable Root - Editable Child Collection - Editable Child setup is for a DataViewGrid Master/Detail View of the data only?

The Master/Detail scenario with that much data does not seem very manageable or does it?

Thanks again Andy,

Kelly.