>>Who's to say that the alias used in the controlsource of the control is the same as the table name? Your interface layer shouldn't have intimate, binding knowledge of the names of backend fields and tables.
>
>I don't assume that, but probe further using a routine from Visual Maxframe Professional.

AFAIK, VMP does not provide for business objects as a part of the framework.

>>Your object is less a business object than a universal validator- business objects are usually domain specific instead of universal, and contain domain specific methods that represent actions that can be performed on the represented entity.
>
>I see what you mean. My concern was to find a more practical way of implementing validations than as methods of an object.

There is nothing wrong with having a validator object. COMCodebook uses one (a separate one for each business object). It's just not a complete substitute for a business object.


>A middle of the road approach would be to base the domain specific business objects on the universal validator.

I think that this would get you closer. You then have the ability to use separate 'rules' tables for each object. But then again, if you have a separate object for each entity, what's the matter with a validation method in each? Unless you need to allow the user to adjust validation code themselves, I don't see much advantage to storing code in tables.

Just my .02.