Visual FoxExpress is one of the few frameworks for VFP to include a data dictionary. A data dictionary is very important for application development in general and integrating a data dictionary into a Frame Work is a key feature.
The VFE Frame Work takes advantage of the data dictionary in numerous places. Once properties are set for the various items in the data dictionary those properties persist throughout the application. This approach can greatly reduce development and maintenance time. For example, the Visual FoxExpress data dictionary allows developers to specify that the contents of a field need to be looked up in a table or view. Once these data dictionary properties are set, this behavior is automatic throughout the application. In frameworks that lack a data dictionary you either need to code this behavior yourself, set properties on each control in the entire application to perform the lookup, create a custom control class for each field that has a lookup and remember to use that class throughout your applications, or modify the classes that come with the Frame Work to incorporate features of a third party data dictionary. What's worse is that if the way the lookup needs to be performed changes, using another Frame Work you need to change all of the places in the application that reference the field, where using Visual FoxExpress you simply change the data dictionary. This is just one example of where the Visual FoxExpress data dictionary reduces development time and maintenance. There are numerous other instances where the same is true.
Each of the properties in the data dictionary represents a place where, in a Frame Work without a data dictionary, there is potential for having to maintain redundant information in multiple places.
Of the frameworks that include a data dictionary, Visual FoxExpress is the only one that includes a DBCX based data dictionary. DBCX compatibility is an important feature in a data dictionary because it ensures compatibility with other popular DBCX based products such as the Stonefield Database Toolkit and provides a single point of data dictionary maintenance. VFE 6.0 makes use of the new DBCX2 standard, which is a lightning fast replacement for its predecessor.
Problems with VFE's Data Dictionary
While the data dictionary and the way the VFE Framework makes use of it is pretty well designed, the rules are not observed outside of your VFE ap. I personally would like to see F1 move the code that does lookups and other validation back to the .DBC...(as it was in 5.x) and called from Field/Table rules in addition to being done in the application.
Actually, they wouldn't actually have to have the code in the .DBC... it could remain in a .VCX that you put in the same directory with the .DBC... and the .DBC rules could just call a wrapper function that was in the stored procedures of the database. If the validate class could not be found, a false would be returned...perhaps a visual warning if the startmode of VFP is not COM object or ODBC driver.
What do others think of this?
Implementing the code in the DBC created a lot of maintenance functions and didn't really add anything. It's relatively simple to prevent modification from ODBC. 5.0 didn't suport Create Object from a stored procedure when accessed via ODBC and I don't believe 6.0 does either, so the code would have to be all procedural and couldn't even reference DBCX. The proper way to access data from a VFE application is through the business objects where all of the data dictionary rules are enforced as well as any other business rules. As VFE expands to support additional data sources accessed through ADO or XML for example enforcing rules in the DBC would not be an option.
Category Frameworks, Category Visual FoxExpress
( Topic last updated: 1999.06.25 07:02:49 PM )