>Kevin,
>
>This is one of my favorite soap boxes!
>
>You can bind your user interface controls to a view that is loaded by a business object and still consider yourself an OOP "purist", given the following caveat:
>
>Your user interface cannot know where the data came from (VFP, Oracle, SQL Server, XML, etc.) and all data manipulation must take place via business objects.
>
>Business objects should be designed to serve up data in the format that is best suited to the client, regardless of the data source in tier 3. Some UI clients need data in ADO format, others in XML or HTML. But in this case the format best suited to Visual FoxPro is a Visual FoxPro cursor...hands down! A cursor is simply one of the many data formats that a business object should be designed to handle. It is not inherently "bad". If a user interface binds to data presented in ADO or XML format is this non-OOp-ish? No, it's just another data format!
>
>When you bind a user interface control to a view, you are not binding directly to the data source in tier 3. You are binding to a buffered reflection of a table(s) that resides in the back end. The business object is responsible for adding new records, deleting records and saving records.
>
>If you present all data to Visual FoxPro in the form of objects, you are throwing out a huge chunk of the Visual FoxPro command set. Visual FoxPro is an excellent choice for the middle tier--not because it handles data objects well--but because it's lightning fast at handling cursors. Why force an object data format on a UI client that is clearly better suited to cursors?
>
>The best OOP solution is both object-oriented and optimized. I've seen many developers sacrifice speed for what seems to be more "OOP-ish", but as in this case, it's not necessary.
>
>Regards,