Hi Marc --

For the sake of brevity, I've chopped off the long thread of replies. Anyone can just hit Previous if they want to read it.

It appears that you are actually arguing the same point I was originally with Jim and John until I realized we were talking apples and oranges (Thanks, JVP, for pointing that out to me).

As to your points, they are well taken. The complexity issues of n-tier design come into play mainly with physical n-tier systems and not VFP, IMHO. This is the point that I was trying to make. The fewer DLLs, RPCs, that is, physical objects in an enterprise system often the better because of resource, bandwidth, and latency issues.

I don't have that hard of a time separating the tiers. Sometimes, I would agree, n-tier philosophy has to be compromised to create the more efficient VFP application. For example, in a situation where the application will never grow, why introduce another "tier" by using all views?

OTOH, if you have developed good parent classes and frameworks over time (JimB, please validate this point I'm about to make) then the client benefits from that foundation and the "complex" application is actually delivered in less billable time and more bullet-proof.

There is a fine line to walk between delivering a solution based on good practices as opposed to "getting the job done"...there is no one, true answer: Sometimes the architecture-centrics are right, sometimes the programming-centrics are right.

There is a great discussion of this issue in the March 1999 issue of Component Strategies magazine; I believe that you can find it on the Web at www.componentmag.com.