Rocky explains in the book the difference between a root object and a child object. Here is what he writes:
----
For example, an Invoice is typically a root object, though the LineItem objects contained by an Invoice object are child objects. It makes perfect sense to retrieve or update an Invoice, but it makes no sense to create, retrieve, or update a LineItem without having an associated Invoice.
----
I am not sure how to deal in a situation I want to add a child record to a parent, without going through the whole process of loading the parent object, and saving the parent object.
Example: I allow adding multiple notes to an invoice, so I would create a collection object "InvoiceNotes" and a child object "Invoice Note", and I would add a InvoiceNotes object to the root Invoice object. However, if I just want to allow the user to add a quick note to an invoice, I cannot use this approach, because I would have to load the Invoice object before adding notes, and then save the invoice object. The other way to do it, is to add a Root object of InvoiceNote which has it's own save, but then I have to repeat logic in 2 places, in the child object (when I load an Invoice) and in the root object.
I have this question with alot of children objects which I want to add it without loading the full root object
Please help...
On page 391 he talks about switchable objects that can be instantiated as child or root objects.
Heath
Depending on your use case, you may want to have a different Root object be the parent for your Invoice Notes collection.
In my code I have Use Case Controller objects which are Root BOs for a given use case. This controller has all the properties of a normal root CSLA BO like Validation Rules. But its main function is to host all of the different BOs required for a given use case. So if I need a child Invoice Notes collection, it acts as the parent Host. If I also needed a couple of dropdowns on the screen it would host the 2 NVLs. etc.
The only real "catch" here is that a Child Collection often takes a reference to a Parent BO as part of its update method.
In this case you need to decide if you need this reference or not. I have found that in many cases I do have the reference but in fact only need the primary key value from it so I can update data correctly.
Therefore I created an Interface named IParent with a single property named Key.
Then I implement the interface in the "normal" Invoice root BO and have the Key return the mInvoicekey value.
I ALSO implement the Interface in the Use Case Controller BO and have it return essentially the same value. (This root BO probably has a Fetch method which takes the invoicekey value so that you can fetch the right set of invoice notes.)
Now in your child collection of Invoice Notes you pass a reference to IParent (instead of Invoice) and then use the IParent.Key property wherever you used to use Invoice.Invoicekey.
Joe
PS - Rocky has added an IParent interface with an altogether different meaning. Either change the nae in the example above or provide namespace separation.
Thank.
But what happens now the InvoiceBO does not the InvoiceNotesCollection. So when I save an Invoice I have to call save now on the new Invoice Notes Controller object?
Copyright (c) Marimer LLC