>>Hi,
>>
>>So far I have been creating one BIZ object for one table. But I am wondering if there is a better design for cases of parent/child tables and ancillary tables. For example, P.O. Header table and P.O. Item table. One approach I am considering is to instantiate P.O. items BIZ object in the INIT of the P.O. Header BIZ object. And then "deal" with any updates for P.O. Items within P.O. Header BiZ object. How do you design your BIZ objects for the cases of parent/child tables?
>>
>>TIA.
>
>I usually just create a property for the child table on the parent table's bizobj. I have an _Access method on it that instanciates the child if it isn't already instanciated. Having the property just makes it more convenient to get to both objects. I've found that I've never been all that happy with bizobjs that try to automatically try to handle things like saving of both parent/child at the same time as a "generic" method. There always seems to be some special thing for each situation that has to be handled and I'd rather just handle it directly instead of having to edit 20 different hook methods. If the logic is straightforward I'll just override the Save() method on the parent. If it's more complex, I usually create another "Process" class that handles the interaction for me - it handles all of the interaction between the classes.

Thank you very much. I have had very similar experience in working with biz object for two or more tables. And I thought I was missing some very basic concepts. And I also thought about creating some properties in the "primary" table BIZ object to "hook" BIZ objects for "child" or "secondary" tables. This way, my basic BIZ class can be used in a simple case and in some more complicated ones.