To paraphrase one famous writer: starting n-tier is easy, I did it myself hundred times :-).

>Hi John,
>
>First of all, let me say this in a loud and clear voice: I'm all for n-tier and I'm trying to implement it wherever and however I can. Even if I did not do so, I would say I do in these pre-break up monopolistic times where you clearly won't beat'em, so you join'em (I hope the tongue is visible in the cheek) :).
>
>That being said, let me say this: n-tier as defined in the latest posting of Jim is a programming style that is more or less forced upon us, not so much by the OO paradigm against which I think it is an infringement (I'll try to demonstrate this in a moment), but rather by the shortcomings of the language and the idiosynchracies of information processing and it's reliance on relational systems for persistent data storage and most of all plain and simple performance considerations, no matter what JimB has to say here.
>
>>
>>You don't have to be a computer scientist to run through an architectural phase on *any* size project.
>
>No, but it sure helps, does it not? :).
>
>>
>>IMHO if you follow a good methodology (preferably OOAD) to model (paper or prototype) an application before coding, then some of the tiers should start to emerge from the design.
>>
>
>Here is where I totally and fundamentally disagree with you. When I look at my analyses, I see a lot of objects that
>
>1. should be able to save themselves
>2. should be able represent themselves preferrably on screen and/or on paper.
>3. should know which rules apply to it.
>
>You see where I'm getting at no? All your analysis objects are represented in all three of you tiers as you defined them. So to say that I would "naturally" regroup my objects from analysis into groups (of objects) along the lines of the n-tier model as it is most often represented is most questionable.
>
>If you do do it, it is for what is called "packaging" reasons at best (the ability to switch between dbms systems is a case in point), related primarily to implementation considerations, but certainly not for modeling reasons.
>
>And that explains the difficulty to pass from ooa/ood to oop. Because there is no mapping at all. The tiers cut right through each and every object that you can come up with in the analysis (read user oriented) fase.
>
>I think that you have to be blind not to see that, or like the rest of us, have forgotten how ideally, the development should follow smoothly via design from the analysis, or systems specifications.
>
>Is there anybody here who could tell me why it is desirable to be able to switch between DBMS's. Is there anybody around who's tried to explain _that_ to their clients? And how billable are the hours you spend "generalising" systems that at best are reusable for your next projects?
>
>Do not get me wrong, adaptability to DBMS's can be an worthwhile objective, but it is not necessarily a requirement, so why build it into you methodology.?
>
>John, you must have said somewhere that "programmatically correct" projects are more expensive, and you were damn right. And have you asked yourself correct for whom? Not for the user. For the design and for the shop. That sounds very much like pre PC rethoric to me, where the user and the client did not understand anything anyway ...
>
>>As Jim succinctly pointed out to me, n-tier is a design philosophy. Within a single language platform like VFP it's easy to experiment. Lets look at the three basic tiers:
>>
>>Presentation tier (UI, screens, reports)
>>Business Services tier (validation, business computations)
>>Data Services tier (read/write data, prepare queries, et al)
>>Data store (the physical DBF)
>>
>>Sometimes the 3rd and 4th tiers are combined.
>>
>
>Hey, sure you do it like that, but because you have to, not because you want to. It makes things more manageable and technologically more adaptable, but it is neither easy, nor natural.
>
>Easy and natural would be that a account could make sure that it represents itself on screen, on paper, that it knows how to save itself, to load itself and what rules apply to it, no matter which properies are defined. IN ONE LOCATION please, independently from all the rest of the system. Then you could reuse at the analysis level and then the sky would be the limit.
>
>>Look at the way you already build VFP applications. Do you have an Application object? Odds are you do so there is a rudimentary Business services tier. Do you have forms and reports? Then you have a presentation tier.
>>
>>Do you use remote views? Then the DBC connection and the ODBC function as the transport mechanism of a Data Services tier.
>>
>>I guess what I am saying is that, by definition, most VFP applications are already inherently n-tier .
>
>Yes, but talking like that you are saying that 1+1= 2. You're not saying why.
>
>Do not tell me that taking advantage of databinding is not more efficient than not to. That visual programming is less effective than generating tools and then be able to get the same results in more time, and probably paying a bad performance price. That Seek, gather and scatter are time consuming and slow. That views are faster :)
>
>And that maintaining a COM oriented system is not a nightmare. Have you tried to keep an ODBC connection stable through the development phase? What you forget is that you have to LEARN each those components and that it takes time, not because it is difficult, but because the quality of the documentation is soooo poor. Do _you_ take the hours spent in trial on error into account, can _you_ bill that? Of course not.
>
>So what am I saying? I'm saying this: Sure, it is good programming to regroup your objects into subgroups. Sure one way of doing this is applying the layers as you define them in traditional n-tier programming, and at this time it is probably a necessity considering technological and economic factors. But n-tier programming is a patch, and it does not ease the path to OOAD, much to the contrary.
>
>Voilà.
>
>Kind regards.
>
>Marc