Paul,

> Along the same lines, it's not really correct (in terms of 3-tier development) to reference your views as control sources for your controls, is it? Shouldn't they be accessed via properties of your business object? Unless you've already written your apps to provide everything through properties wouldn't you need to rewrite most of your business objects to provide this functionality? Or, would your class views instead be mapped to a ADO/OLE DB/??? object instead?>

Although some have recommended storing the value of view fields in business object properties, I do not agree...because it hobbles Visual FoxPro where it shines best...cursor manipulation.

In the Codebook methodology, Visual FoxPro view fields are a direct extension of a business object's properties. The business object is responsible for loading/unloading its associated data into the form/report's data session. All data manipulation (saving, adding, deleting, etc.) takes place through the business object.

We have always advocated using views in conjunction with Codebook's Dynamic View Cursor class to make the data source (whether it be local FoxPro tables, remote SQL Server or Oracle) transparent to tier 1. This makes the transition from local VFP tables to client-server easy AND this methodology still works well when moving to technologies such as ADO.

In our Visual FoxPro 6.0 version of our framework, we will provide ample information on transitioning to a true three-tier architecture (including ADO). For now, you can continue to bind your user interface controls to view fields with confidence that a smooth transition will be provided by means of advancements to VFP 6.0 and the Codebook for Mere Mortals framework.

Regards,