>>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?
>
>I usually treat child tables as belonging to parent table BO, therefore no separate object for them, unless they have use independently from parent table. In other words all handling is done within parent BO. All my BOs are based on session object (parent class) and done inside PRG. Here is one over simpliified mockup example ;
>
>

>local oBO
>oBO=createobject('MyOrders')
>
>oBO.ShowList()
>
>oBO.EditOrder(993344)
>oBO.DeleteOrder(993344)
>
>oBO.PrintOrderList()
>*etc
>
>
>define class MyOrders as myBO &&parent class based on session object
>
>
>  procedure OpenTables
>    **open tables directly or fetch data from backend
>     use Clients in 0 shared &&order ...
>     use Orders in 0 shared
>     use OrderItems in 0 shared
>
>  procedure ShowList
>  **show some form so user view / select from list of orders
>
>
>   procedure EditOrder
>   lparameters nOrderId
>     *show order form
>     local ok_pressed
>     do form (cOrderScx) with this to ok_pressed
>        if ok_pressed
>         this.SaveAll()   &&parent class generic method or subclass specific 
>          else
>        this.RevertAll() &&parent class generic method
>       endif
>
>
>    procedure DeleteOrder
>    lparameters nOrderId
>    **Show dialog
>    **delete  child records
>    **delete parent record
>    this.SaveAll()
>
>    procedure AddOrder
>      *add new record 
>      *show edit form 
>     local ok_pressed
>      do form (cOrderScx) with this to ok_pressed
>      if ok_pressed
>        this.SaveAll()   &&parent class generic method or subclass specific 
>      else
>       this.RevertAll() &&parent class generic method
>     endif
>
>
>    procedure ValidateOrder
>         *validate record 
>
>    procedure ShowLookup
>       lparameters nCustId
>      *show lookup form
>     do form (cOrderLookupScx) with this to nSomeRecordId
>     return nSomeRecordId
>
>    procedure PrintOrderList 
>       *extract / preprocess data
>       report form (cOrderFRX) to printer preview
>
>    procedure CalculateOrder
>    **calculations
>
>
>
>     *etc
>
>
>enddefine
>
>
>define class myBO as session  &&parent class for all BOs
>
>   procedure init
>      this.OpenTables()
>
>
>   procedure SaveAll
>      *depend on architecture, saving buffered data or sending updates to backend
>
>   procedure RevertAll
>      *depend on architecture
>
>   procedure DeleteCascade
>
>*etc
>
>
>enddefine
>
>
>

>
>
>You might frawn at use of prg, but flexibility you get this way is just simply amazing.
>You can call these objects literally from anywhere (can be even exposed as COM object), related BOs can call each other
>very easy, you avoid Form.DE problems, get much better (fully controllable) *formset* (set of connected forms) and many other things. You pass entire object to all forms that are called, store object reference in some property and then all UI forms can call their undelying BO methods very easy.
>
>

>
>**form init method
>lParameters oBO
>this.oBO=oBO   &&store BO object ref to form property 
>
>**Then anywhere in the form code (Some button click method, textbox validation etc) 
>*some form method
>.
>if  thisform.oBO.ValidateOrder() 
>
>  **action  when valid
>  else
>  **action when invalid
>
>endif
>
>
>
>

>
>Forms should contain as little of code as possible themselves. Just some controls handling if necessary and calling
>BO methods.
>
>Worked very good for me for past 10 years or so :)
>
>
>HTH
>Sergio

Srdjan,

Thank you for your input and sample code. Logically your approach is similar to what I have done so far. And what I find that majority (at least of those who responded here) use one BIZ object for parent and child table cases. I will turn to this approach too (up until now I was creating a separate BIZ for parent and a separate for child).

There is nothing wrong with use of .prg. I have just adapted (for ease of working) using visual classes. I know that visual classes add overhead to the .EXE but I am not worried about it. My main concern is to reduce the application/code maintenance. Speed of instantiation or processing is also not important; hardware becomes more and more powerful.

Again, thank you for your input.