>1. bizContainer class. Instantiated as global variable. Provides single point of call.
>1.1 Properties: Those needed to keep track of AddObjected bizObjects.
>1.2 Methods:
>AddBizObject: AddObjects biz object to itself;
>ValidateField: Passes call to appropriate BizObj
>ValidateRecord: idem

So if one atomic piece of code needs to validate a record, it has to instanciate a global object that instantiates every business object in the project? Why not make the business object atomic so you can just use one if you only need one?

>1.3 Example of use: Permits generic calls in the framework, such as oBiz.ValidateField(This) within the valid of interface controls.

I think you want to stay away from passing a control as a parameter. What happens when you want to use these business objects from a web page, or an Excel spreadsheet? You would have no controls to pass.

>2. bizBase class. Base class for BizObjs.
>2.1 Properties: RuleTable, DataTable. Empty here, defined in subclasses.
>2.2 Methods:
>ValidateField. Generic code that looks up code in RuleTable and executes it.
>ValidateRecord. Similar generic code for RecordValidation.

Agian, if you're going to go so far as to create individual business objects, why not place record and field validation code directly in the methods of objects? I still don't understand the proposed advantage of storing code in tables.

>3. bizXXXX. BizObj class for a specific entity.
>3.1 Properties: RuleTable and DataTable defined here.
>3.2 Methods: Besides those inherited, contains “domain specific methods that represent actions that can be performed on the represented entity”.
>3.3 Example of use: oBiz.bizEmployee.AccruedVacation().
>3.4 If this class is defined in code, it eases the maintenance of the “domain specific methods”.

I don't follow.

> I am trying to do it in a way that is practical for my programming style (it leans towards code).

I program using code too. :-)

BTW- you might check out some of the object oriented frameworks out there for ideas on how to implement business objects that will be usable from most any scenario. And check out Markus Egger's OOP book.