>>>> 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.
>>
>>Agree totally! If we as a VFPers develop our apps using the "design ideas" of n-tier approach, even in our VFP-only type of apps, we should be one-step closer when the time comes to actually "physically" separate a layer to handle access from other clients, etc.
>
>Actually, two steps would be required, and while the separation of data is logical enough, the separation of GUI seems terrible (IMHO).

Can you tell me what you mean by separation of GUI? Are you referring to data "unbounding" of controls or using a different program (e.g. Excel to access the data)?