Hi!

>>
>>It is VERY depended on the application you going to make. Some approaches have quite different advantages|disadvantages. In particular, you did not included the usual VFP query to the VFP database, WHY? VFP query result cursor could be passed between COM objects as a string with a great speed, indeed (See DCOM tests in downloads section here).
>
>Each has different advantages and disadvantages but it is a rare development house that will be able to learn all of them. The ideal design for one application may not be for the next, but learning a new technology every application is not an option for most people. So I suspect that the real paid for applications (not test applications) tend to be written with the same design at a given company.
>

Its not true. The way you use to access data is mostly depended on the customer. When you use only one way, you make self do not accept a range of customers that want to use tools that you do not use.

>>>2) Do you use a framework? If so which, and is it better than sex?
>>>
>>
>>It is not better than sex because you will require to do a lot of things even with framework. Framework will allow focus on real business logic instead of playing around technical details, that usually speed up the development (and so you can have more sex ;)

> So I take it you don't use a framework? Uhm maybe I should rephrase that. Do you use a framework? Again with frameworks it's not like you have the time to learn all of them. People become committed to frameworks and use them for several years at least.
>

I USE frameworks, as I said, it usually speeds up the development and time spent for framework learning quickly returns to you.

>>
>>>3) How many tiers do you use?
>>> a) Two: Client and Server.
>>> b) Three: UI/Business/Data
>>> c) Four: Which?
>>> d) Seventeen: one for each dimension of the universe during the big bang.
>>> e) Other
>>
>>It depends. When you want your system be really expandable, make it 3-tire from start with prediction to enhance it in the future by more tires. Test it, then enhance. You can have as many tires as needed. This is not limited to phisical use, you can have application with 100 tires in a single EXE, just they separated well logically and easy replacable (for example, using some sort of dynamic modules) or data driven (logical models of application behaviour described in the data - remember that VFP EXE can run code after reading it from teh database memo field ;)
>
>So I take it that you use different arrangements for different problems rather than having a standard approach that you use? In my case I always need more than one tier -- the business layer must be separate from the interface simply because of the necessity of handling file imports for the sort of applications I work on.
>

For real-life you cannot develop a standard approach. Putting everything into a standard is a way to make company not flexible, and thus company will not survive in long term. You always should live a hole or even a wide area of flexibility to enhance systems, improve them or change the basic model of the systems you develop - different customers can want different things, and application with GUI for accessing data is VERY different than automatic processing system that handles EMail letters with XML and does some background data processing. These two have completely different standards that are even not comparable, and you cannot develop some standard of development approach that could be used for both of these applications.


>>
>>>
>>>4) What question would you like to have included on this poll? And which questions (other than this -- no recursion allowed -- it leads to too many bugs) are beyond unbelievably stupid into and into the realm of transgalactic stupidity.
>>
>>I would like include a question: How many people around really know and use the n-tire approach, and is it good idea to use it at all? How it is depended on the size of the application and company that will use that application?
>
>
>That's a interesting question. I suspect that nobody knows how to use the n-tier approach in all it's ramifications because it's not a knowable topic. There are many different ways to slice up an application into logical self contained sections and it's not possible (IMHO) to identify let alone understand all the different possible strategies.
>

There are a lot of experiense for building n-tire applications. Take a look to the COM CodeBook tools for development under COM+ (MTS). They have very well developed concept for this kind of applications, and it is developed based on a years of experiense.

>The most attractive element to the overall paradigm, to me as a developer, is that used properly it divides up the problem of development into smaller chunks. One can have a VFP/SQL-Server application with only a single tier. The user interface could make SQLExecs into the database. But this means that the developer has to deal with SQL Server problems at the same time as grid problems and either the developer is very smart or development time is dreadful.
>
>

This also not true. In OOP there are interfaces and implementation. If something could not be implemented because lack of data or communication, you just make request to another developer to change interface between tires, and thats all. Of course, it would be good when it will be as less such requests as possible, that is why n-tire application should be desined VERY well before starting of coding, with prediction of all things. usually such things should do very professional programmers with a lot of experiense, they capable to predict every detail.

>Curiously enough, in the mainframes days people used a two tier approach (though nobody called it that), which was then used at my first job with FoxPro 2.5