I've been considering an aspect of an object oriented framework I created a while back. This framework was based on business objects, much like codebook. A business object is basically a container for a particular part of your buisness.

For example, a rolodex business object would contain all the code to deal with adding / deleting /updating rolodex "members" ("data" in non-OO terms). So, once you have your rolodex object you can drop it on a any form and you would have the functionality you needed. I like the idea that the business object is self-contained--as a good object should be. However, I am undecided on just how far I should take the object oriented model.

One concern is the dataenvironment. The business object is not actually self-contained unless it has it's own dataenvironment. As we all know, the VFP dataenvironement class can not be visually subclassed, only programatically. In programatically subclassing the dataenvironment we are left with a non-visual dataenvironment. I can't decide if staying with the object oriented model is worth the added headache of giving up the nice visual VFP dataenvironement.

Another concern is data manipulation. In a perfect OO world, only the corresponding business objects can deal with any aspect of its members. This means that, in the case of the above rolodex example, only the rolodex business object could modify rows in the rolodex table. However, there are some cases when other business objects need to update that particular table. Does this mean that I now have to instanciate the rolodex business object and submit the proposed changes through it or should the business object be able to manipulate the table directly?

To reiterate briefly: 1. Do you feel that subclassing the vfp dataenvironment is more headache than it is worth? 2. Is the self-contained business object a good thing or should you be able to manipulate data directly?


Any comments are appreciated.