(This Thread is in response to an article by Andy Kramek and Hue Holleran in the Dec. 97 issue of FoxPro Advisor, and to another Thread where a few of us expressed interest in regards to this article. Hopefully we can start a detailed discussion here, and continue it at the Friday Conference on 12/19/97)

Article - Data Classes That Make Client-Server Easier, page 34

The main thing that caught my attention about this article is that it was the first VFP-specific explanation I've seen, on how to use good solid class design to make the 3-tier client server model a standard easily adhered too. Not too mention easily maintained and put into place with lots of room for system expansion/growth. Plus too, as a VFP novice (and thats probably even a stretch ;)) I often have trouble visualizing how complicated classes and inheritance work without laying it out on paper or putting code into place. But this article made it easy to visualize a simplistic but flexible class structure that could be easily handled by a single developer or team.

To quote the authors of the article directly, The Key Features of their Abstract Data Classes are:
- Transparent client-server development methodology
- Single point of entry for solid transaction handling and contention management
- Separation of client interface and front-end processing from the back-end server

The authors go on to state the primary objective when developing these classes was to simplify the creation of a client-server system (Bravo Kramek & Holleran, you did a great job!!) At the simplest level, they determined there were only 4 components needed:
- User Interface
- Application Data
- Server connection
- Back-end querying and processing

This last part is what I really liked the most. Some of you know I've been working forever on designing a rather complicated data warehouse system that uses large amounts of data. And sometimes when your researching and laying out a gameplan that travels through somewhat unfamiliar waters, it really helps when somebody external lays out a road map in front of you that shows you've really have been following the right path (or atleast darn close to it). For me, the road map was when the authors took the 4 components listed above, and showed how to implement them into their Abstract Data Class Model as Form, DataEnvironment, Data Manager, and Database (in that order.)

So ok, thats my introduction of this article and my $.02 worth of why I feel this is one of the most valuable VFP class related documents I've gotten my hands on so far. Lets have some more opinions about why these classes would be useful. I'm particularly interested in anyone's insights as to when an implementation like this might not work, and how the functionality of the Data Manager component might be adapted to a developer's particular needs/situation. So lets hear it... what's everybody else think? :D)