Can someone please explain to me why the need for the IsChild #region, or the _isChild field, in Core.BusinessBase? I ask this because there is already a Parent property in the "Parent/Child link" region. Is it fair to say that the IsChild region could be replaced with:
private bool IsChild
{
get
{
return (this.Parent != null);
}
}
You would have to comment out the check in the SetParent method too.
internal void SetParent(Core.IEditableCollection parent)
{
//if (!IsChild)
//throw new InvalidOperationException(Resources.ParentSetException);
_parent = parent;
}
This way you either have a Parent, and thus are a Child, or you don't have a parent and are not a child.
Thanks
At the moment it is possible for an object to be a child of another object without the Parent property ever being set.
If your object is a child of a collection (BLB), then SetParent() is called and Parent has a value.
But if your object is a direct child of another object (BB), then SetParent() would only be called if you implement the code to call it (any time the child field is set, and when your object is deserialized). That's not automatic, and most people don't make this call. So Parent is null, even though the object is a child.
I've toyed off and on with creating a "child coordinator" object that would fill the role of BLB in this second case. The goal would be to simplify the code in your parent object, and one side-effect would be that SetParent() would be called automatically. But this idea is relatively low on the priority list, and wouldn't solve the _isChild problem regardless, because using the child coordinator would be entirely optional (must preserve backward compatibility with existing code).
IC. That makes sense. I didn't consider the scenarion when BB is a child of another BB. Thanks for the reply.
Copyright (c) Marimer LLC