"Can not directly save a child object"

Question

Not able to save ListeItem Marked as IsChild True,IsValid True and all other flag needs to save child to DB.

Can any one suggest how to get rid of this error in CSLA.

Answer 1

When you have an editable list of child items, or even a single child of an editable business object, the entire object graph from the root level (the parent object) will have a Save() and a SaveAsync() method that will save the entire object graph, assuming the parent and all children do not have any broken business rules (such as a required property value is missing).

So, to answer your question, the way to save a child object (whether its part of a list or not) is to call Save on it's parent root object. Note that only objects that have changes will actually get saved (presumably to a database or an XML file), so saving a child this way, even if there are hundreds of siblings, is quite efficient.

That said, there are indeed times when you'd like to just call Save on just one child object that's perhaps in a list of hundreds of like objects.

The best way to approach this situation, especially if you are dealing with thousands of children objects, is to first create a Read-Only List parent object which contains just the minimum information needed in each child object within the list. Read-Only lists of bare-minimum read-only child objects is far more efficient in code than the same list in read-write editable form.

Now, if a list item needs to have its data edited, then get from that selected read-only object (from the parent list) the unique ID key that represents that object (you want that key to be part of the bare minimum data that is loaded into each read-only object in the list). Then using that key, fetch a differently designed Editable-Root object that fully represents the selected child. Now you can edit the properties on that stand-alone business object and call Save() (or SaveAsync()) on it. The editable object is a standalone root object in this case now.

Effectively this technique allows you to save just the "child" object. It is typically much more efficient than getting an editable list since you'll not likely need to populate all of the properties (of all the child objects) to create the read-only list. The read-only list is used just for finding or selecting the particular object. Once selected, a subsequent fetch of the fully editable object is performed.

So an example would be, say you have an HR related app and the HR rep needs to change some information about an employee in the company. In this case one would create a read-only list of employees to select (or a read-only list filtered by first letter of the employees last name say). When the HR rep selects the employee to edit, the system code would retrieve the unique identifier for the employee that needs to be edited from the selected item in the read-only list. Then using that key field, a differently designed EditableRoot based business object representing a single employee would be fetched. Now in the code one has, in essence, an editable "child" object that can be saved independently of any parent list or parent object. I put "child" in quotes, because the editable object is derived from the EditableRoot base class, and while it represents an employee object based on a selection from the initial read-only list of employees, the root object itself is not physically a child, but a fully savable root employee object.

I use this technique all the time for the right circumstance. The technique fetches lots of light-weight read-only and bare-minimum representations of the child objects that may need to be changed and saved, and only the ones that actually get changed are the ones that are later fetched as an EditableRoot which has all the properties available to edit.

Hope this helps someone using CSLA.NET.