>Thomas,
>
>Right now, I am tinkering with the DataEnvironment (DE) as my BIZ Object, then use CursorAdapters (CA) as 'representations' of each table. Since the DE is a container, it would be easy to handle its CA members.
>
>The problem with that approach is that ONLY the DE can have child objects. Similar to your approach I have child objects where necessary, but not all children are data children - sometimes they are added to provide biz functionality. Data children have a CA associated in a property, as custom cannot addobject them. But this way modelling becomes easier for my way of thinking
>
>Hi, could you be more specific by giving an example? Thanks.

oPerson
-_oCursAdp
-oData
-oFormater && for Reports, XML...
-oValidator  && Field & Rec validation
-oAdress
--_oCursAdp
--oData
--oFormater && for Reports, XML...
--oValidator  && Field & Rec validation

and so on. By .AddObjecting("oValidator", "Valid" + [Person, Adress, Whatever]) the child objects via factory dynamically the design is more flexible: less ovverrides, easy to specialize without creating a god-class-design.
This way I only have to "remember" to handle the _oCursAdp differently, as it is not part of
an object tree with normal vfp containership.
Anchoring such a design on CA's would imply to handle oFormater, oValidator et al. as properties via fwk methods
duplicating normal vfp handling - it is less "unusual" to keep track of the single _oCursAdp in each biz object. Also I have the Childobjects bearing data easily accessible via loChild in this.objects[] + if Type("loChild._oCursAdp.Name")=="C"...

Hope it is clear enough

thomas