I agree with you. I can have 3 classes (presentation, business rules and data) to handle all the process.

However, when the business rules class needs to perform operations on the data then the problem comes. I have 2 options:
(1) Let the data class perform __all the data access__ and pass the data in a standard format to the business rules class. Then the business class will always work with the same set of data no matter the source (i.e. no matter the source table structure, no matter the source database manager system.)
(2) Well... I guess the previous method is the only one that really works :))) I think I just realized HOW can this be done. I used to think this as a 2-tier strategy (where business rules are spread over the 2 layers and there the lack of reusability).

I will try to switch my brains from 2-tier to 3-tier! :)


>>I created a class to process 'Work Order Items'. Nothing special: quantity, item, price and total.
>>
>>My class has a property for the alias, so it can work with several different alias. The class assumes that the field names are going to be the SAME in any alias that I use. This make the class very limited. Not as reusable as I would like.
>>
>>Now, lets make the field names dynamic as well. I added 4 more properties to let the programmer specify the field names. Now everything needs to be defined in the properties and I lost all the visual stuff from VFP.
>>
>>Now, to get the item name and item price I need to look another tables. Hum, here we have the same problem. The look up tables needs to have the same structure for all the instances that pretend to use this class (or I need to make everything a property to let VFP redirect at run time.)
>>
>>Shouldn't I been working with objects and forget about the underlying structure (tables structures)? After all I can just add Load and Save methods to my classes and put there the table-specific code. That will make me an truly-OO guy. Well that also will make me lost a lot of the VFP database capabilities at some points (the code executed between the Load and Save methods - and there will be a lot of code.)
>>
>>So, I have 2 options:
>> * Be truly-OO and lost VFP database capabilities
>> * Use VFP database capabilities and forget about reusability (true reusability)
>>
>>
>>Which one is the better? Why?
>
>
>The beauty of OO is that you can have your cake and eat it.
>
>IMHO, the best way forward here is to use two objects. One to handle things at the Business rules level, giving you true OO data, then another to handle the specifics of low level data management.
>
>The business level object can process data in a generic fashion, referring to the low-level object whenever physical data access is required.
>
>The low-level object can then be subclassed for whatever physical data storage is being used (VFP, SQL Server, etc.)