> I don't think it's a really bad idea but wouldn't this be too restrictive? I think one of the advantages of n-tier is the separation of each layer to function w/o too much regards to changes in the other layers. If you don't separate the middle-tier in to separate EXEs or DLLs, you would "corner yourself" in to VFP-only solution. Just my simply opinion.

It's not necessarily restrictive. As long as objects from one layer are never physically inserted into another layer. IOW, if CreateObject() or CreateObjectEx() are always used to instantiate elements from each of the layers then replacing a VFP component with a COM/DCOM object should be rather trivial. This approach makes a lot of sense for people that want to start to get a handle on n-tier development but don't necessarily need it just yet or aren't quite ready to step outside of the friendly confines of VFP. It let's them create applications with an n-tier architechture that are ready to respond to future needs of a different front-end, COM services to enforce business rules or a different data manager and they still get all of the benefits of logical separation. The real obstacle here is that most VFP developers still bind objects directly to data which eliminates the possibility of truly separating all of the tiers.