Decomposition and Child Objects

Curtmantle posted on Thursday, September 11, 2008

I'm a relative newbie to CSLA and I have a quick question regarding decomposition.

If I have a class that I wish to "inherit" from using decomposition - should the object that I am wrapping be marked as a child?

I'm an old hand at inheritance - never had any problems with designs nor maintenance. Decomposition is so inelegent, but CSLA seems to favour and encourage it.

Thanks

triplea replied on Thursday, September 11, 2008

If the resulting object is conceptually a root object in your use case then there is no need to mark it as a child. You should look at it from a use case point of view not from your class hierarchy.

Curtmantle replied on Thursday, September 11, 2008

Thanks. In the example I'm thinking of, it is conceptually a root object.

The problem I was having was one of not being clear whether there is a technical reason within CSLA to mark it as a child, to ensure the relationship was maintained. However, as the "parent" is wrapped, I can ensure it's being updated and not being presented to the public interface - but I wanted to check.

I need to look up what marking an object as a child does in technical terms within CSLA really.

triplea replied on Thursday, September 11, 2008

Well the book would be the best guide, I wouldn't even attempt to list the reasons. But it also depends what version of CSLA you are using. In CSLA 3.5 there are a lot of enhancements that really reduce a lot of repetitive code and make the relationship more distinctive.

ajj3085 replied on Thursday, September 11, 2008

Usually a child object is one that you cannot call Save directly on; it's up to it's parent object to ask it to save, usually through an internal only method, or in 3.5, via a Child_Update or Child_Insert data portal method.