For one thing, much of the concept of a 3 tiered approach is not done simply
because we are trying to "scale" the application. A 3 tiered approach can
certainly help in the scalability since the business logic is running on the
server side, and NOT client side. Stuff like update code etc runs server
side, and thus does NOT cause network traffic.
However, the main thrust/reason for that 3 tiered approach is that we don't
want the business logic on the client side. Besides, a browser and some
little scripts is not the best IDE! In fact, writing code in ASP pages is
not that hot either.
However, why not use a 2 tiered approach? Why not simply put all the logic
into stored t-sql procedures?
The problem is that t-sql is a real lousily development platform to write a
payroll system. In fact, t-sql is not enough of knife for anything that has
a large degree of complexity. Don't get me wrong, but t-sql is fabulously
fine language for writing some sql update code. However, when you need to
write a complex payroll system, t-sql don't even come close.
Thus, to develop modern software ones needs a REALLY GOOD IDE AND DEBUGGER.
In other words, I need a fully powerful development platform with
subroutines, functions, objects, and all kinds of stuff that developers have
come to expect in any good development language. A good debugger, some
source code control is also needed for any large project. One needs the
whole nine yards for any serious software development.
Problem is, t-sql offers NONE of what we would call a rich development
environment. You can't un-leash a team of developers and say write a payroll
system in t-sql. It don't cut the mustard. You don't have objects in t-sql,
let alone simple things like collections etc.
So, developers quite quickly learned that the ONLY solution was to develop a
middle tier with the code. That middle tier is written using a good
development platform . As mentioned, the side benefit of this approach is
better scalability then a 2 tiered (thick client to sql server). With thick
client, the business logic is on the client side, and that causes additional
network traffic. There is also benefits to removing the business logic out
of the UI. So, the need here is a good IDE, and the code has to run server
side.
So, the whole com/dcom object idea in fact HAS caught on quite well. ASP.NET
and the new .net tools actually follow this 3 tiered model very well. Those
tools allow a incredible rich server side development platform. In fact, we
are even seeing some debates by some as to why even bother to use stored
t-sql procedures anymore! As long as the code is running server side, it is
not such a big deal anymore. It was not that we needed OO, or we needed a 3
tiered, but simply that developers were desperate to develop software with
good tools, and that software needed to run server side. To bad that in
place of t-sql we did not get vb-sql!
Regardless, all the basic use of things like reocrdsets etc can be used.
There is no need to "abstract out" the recordset code to something else.
Many now are actually suggesting that even more code be moved OUT of
sql-server into the middle tier. Also, moving the business logic to that
middle tier means LESS dependence on the front end and LESS on the server!
For best performance, stored procedures should still be used, but really,
most of the time if the code/data processing is running server side, then
all are quite happy.
All we really want is a nice rich development platform that allows rich
server side development. MS has given us that with the .net tools......
If you are developing small business applications, then I think a 2 tiered
approach with ms-access to sql-server is fine. The beloved ms-access is
still the best tool for most non web based business applications.
My thoughts on thin client vs .net:
http://www.attcanada.net/%7ekallal.m...tsand.net.html
My thoughts on when to use class objects in ms-access:
http://www.attcanada.net/%7ekallal.m.../WhyClass.html
--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
ka****@msn.com http://www.attcanada.net/~kallal.msn 
