Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
10 Things to Avoid in VFP Development
Message
De
03/01/2000 20:49:52
 
 
À
03/01/2000 20:22:58
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00310318
Message ID:
00312071
Vues:
40
>>How have you dealt with this? [COST]
>
>Generally, the client provides the impetus for moving off the native platform; not all, or even the vast majority, of my system deployments use a backend to handle their data, especially when first implemented. If the application is not dependent on non-native-data file handling features for its basic operation, you can and should deploy with the native engine. My belief is that you want to take advantage of the SQL portions of the language in preference to the older procedural constructs; in most cases, it's less work to develop the data services layer this way. Doing this also helps later when you need to move to the backend environment; the same basic techniques and code style is used to manipulate the backend to extract and update data. I don't have to rethink the data services layer stratgey from a process-centric representation to a solution-set-centric representation.

I agree that this approach make a lot of sense. I need to be able to go either direction depending on the client.

I'm using Visual FoxExpress 5.0 which offers local views as an option. That makes it a lot easier to go to remote views. (I believe VFE 6.0 offers the same feature.) I chose to use local tables because I was new to VFP and there was so much else I had to learn. I think I made the right choice. Getting up to speed with O-O and visual programming in general was hard enough for me. (Don't learn as fast as I used to.)

JVP, for one, doesn't like local views. What's your POV?

BTW, Ed P. -- do you see the argument in my case (building a marketable app that can deploy with either VFP DE or SQL DE) for using lots of SQL and staying away from xBase only features?

Ed R., I'm intrigued by the idea of writing a middle-ware UI-less VFP app that can store data in VFP tables or in an SQL DB. The front-end would be written in VFP but would send the data to the VFP middleware program running under Win2K for storage via XML. The VFP middleware app could run on one of the dual-processor RAID super-machines that you describe. Seems like VFP could store data in local tables much more reliably this way. I might need a separate middleware VFP box for batch operations.

West Wind Web Connection would certainly be useful if I went this way. Any thoughts on this approach in general?

Peter
Peter Robinson ** Rodes Design ** Virginia
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform