>I have a general questions about using Business Objects:
>
>What is the best or proper way to handle a parent/child scenario? What I mean is would the parent and the child each have a Business Object to manage each of them?
>
>Consider the typical Invoices and LineItems type scenario. Would I have 1 Invoice Business Object and 1 LineItems Business Object? I know some would say that each LineItem should have a Business Object, but I’m not sure that is the best way either.
>
>So if I want to delete an Invoice, I would ask the Invoice Business Object to Delete() and I would assume that would also ask the LineItems Business Object to Delete() all if it’s lines, right?
>
>But what if I want to just delete 1 LineItem? Do I just ask the LineItem Business Object to Delete()?
>
>Thanks for any advice, I’m floundering at this point as to how to do this stuff right.

I would start with a "base" Business Object. The "child" would be a subclass of the Base; it would have many properties and methods in common with the parent. A few properties that would be unique to the child would include: Parent Key (value), for instance.

I think it would be easier to think of these Biz Objects as "collections"; frequently they will be asked to perform an operation on a "set" of Invoices or Line Items.

A "linked list" (array of child object references) could be maintained from the parent (collection) to each child (collection), similar to the functions of RELATION() and TARGET().

(In effect, you build a model in software similar to an Entity-Relation diagram).

As for deleting Line Item(s), this could come from the Parent (eg. The Order is cancelled and deleted; the Parent supplies the "parent key" and the child DELETES ALL FOR ...). A delete, whatever the source, would primarily involve a complete or partial primary key: a partial key implies "all items for an Invoice", a full key (eg. Invoice + Line #) implies a single line delete. The Child might perform a "callback" to the Parent and pass some "control totals"; eg. lines deleted, amounts) ... or the child might have an actual Parent reference that was added when it was instantiated and it might update Parent properties directly.

It could be argued that for the sake of simplicity, all "file requests" should be made thru the Parent and then dispatched from there; this would provide a single entry point into the Model. You could use "keyword parameters", or invoke child methods directly; eg. m.oInvoice.oLineItem.Delete( ).

(Whether any of this is "best" or "proper" is a matter of opinion).