>>Here's the reaction of the less gifted developer in the street who has no >other tools at his disposal than his bare VFP... :).
>>
>>The question is how do you get there. The trouble with n-tier is that it >requires rigorous system requirements and sharp design.
>
>[JVP]And a well designed single-tier app does not?

Not necessarilly, and it is in these circumstances that VFP is at its strongest. Not all projects have bullet proof system requirements, and yes sometimes you do have to iterate before the user's needs become apparent.

The positioning of VFP with its all tier in 1 package somewhere between Access and C makes it possible to introduce technology in organisations that would otherwise not be able to adopt is.

>>And the fun with VFP in small businesses, where problems are not too complex but rules and procedures are not very well defined, is that by the time these two requirements are realised ... the application has already been developed, admittedly in a first version.
>>
>
>[JVP]So, whether you design your app as a single-tier or n-tier, if you start coding before the design is set, you are in big trouble. Once again, I don't see the distinction...
>
If I could, I would invite you over at one of my clients. We're not all writing packages to be distributed, some of us work directly with our users, and believe me when you do that, you do not need more complexity in you development tool than strictly necessary.



>>It is difficult in such an environment to even adapt to a methodology that goes in the right direction, and _eat_ (read feed your family) at the same time.
>>
>>And this for 2 reasons:
>>
>>1. The amount of work is substantial, when compared to the average project.
>>
>>2. Before you are doing n-tier ... you are not doing n-tier, I mean, and I think you will agree, that n-tier only gives results when the full paradigm has been implemented, there's no such thing as half n-tier, or half oo solution.
>>
>
>I think Jim Booth said it best, anytime you componentize your app, you are doing n-tier. True, the classic implementation is spread out over multiple machines. However, I do not subscribe to that classic/pure defintion. When I first learned Fox, I would stay up till 1-2 in the morning, learning the language. If you are somebody who does not like change, likes the status quo, you picked the wrong business.
>

John, who's flaming here? :)

>>Tough you'll say, well ... maybe not. What we need in these discussions is not so much a defense of n-tier, but paths to get there. In other words, if you are not yet n-tier
>>
>>Where do you start?
>
>Read the current literature. Take a small app and convert it. You will make mistakes, but then again, that is the only way you learn.

Talking about answers out of the manual :) (joking). Seriously, that is not the way. With OO, I have always regretted it when I was too ambitious. Implement classes yes, but slowly and do not think you have to do it all at once. At best, at the end of the road you will end up with a hybrid system anyway, so it is really only a matter of degree of OOness.

OO, the Grajower way.

Thanks and kind regards,

Marc