2-tier -vs- 3-tier

Can anybody help me develop an argument against the statement:
-don't develop 3-tier applications...just develop 2-tier applications using VB & SQL on the backend.  Call all stored procedures that contain the business logic.-

Any help would be appreciated.

thank you
Who is Participating?

Improve company productivity with a Business Account.Sign Up

renaissanceConnect With a Mentor Commented:

The issue determining the number of tiers for use with your application is not as simple as 3-tier is better than 2-tier or vice versa.  there are many distinct advantages to having as few tiers as possible, as well as having a multiple number of tiers.  for the most part, uchmidtz hit it right on the button with his final comment when he said: "Not every application requires three (or more) tiers. Let the application architects decide what is
best! ".  to understand n-tier architecture, you truly have to understand object oriented programming on a wide scale application level.

tiers are an attempt to simulate an object oriented environment on a large scale, not simply with classes and simple objects but with applications.  in actuality, each tier is it's own application with an interface that other applications can use.  the real idea behind it is to split functionality into its basic parts so that distribution and maintenance are simpler (not easier), so that no program knows more than it needs to.  in a true two-tier database application, you have your user application, and your database management system.  This really means that your database system handles all of the data processing and storing, while your user application handles everything else.  This in actuality is not a bad way ot handle things because in general in it easy to debug and easier to distribute.  this also makes your clients 'thinner' because it doesn't need to know what to do with the data.  it just simply passes it on the the dbms (or rdbms ass it were).  There is also less to distribute, and it fits in line with the 'natural way' that programmers program.  in general, costs are lower for development, development is in many cases faster, and design flaws affect the 2-tier system less than they affect a 3-tier system.  however, applications are bulkier, debugging costs are higher, and any code additions or subtractions affect the entire application, making debugging a nightmare in most cases.

3-tier and n-tier systems can help many of the problems that 2-tier systems present, but at a cost.  in a n-tier environment, functionality is divided into its basic parts.  this means that if there is a problem with functionality, you will only ever have to look in a couple of places; clients are thinner.  however, distribution can be a nightmare, design flaws become more apparent and more important to avoid, development takes longer and costs more, and it does not follow a natural way of thinking and performing tasks.  by this last statement, i mean, if you are told to go pick up some bananas at the grocery store, you handle the transportation, the barter, and everything else because it is easier to handle it all yourself in terms of thinking regardless of how many tasks you have to perform to get the job done.  in actuality, the work load is significantly decreased if you simply have to make a phone call and 'poof' you have the bananas sitting at your front door handed to you by a delivery boy.  however, let's say that the delivery boy messed up your order and got you oranges instead, or that all of the grocery stores were out of bananas, or that, you misunderstood the cost of the bananas and the services for the delivery boy. all of these can be related to 'interface problems' and you face them everytime you discuss n-tiers because your application doesn't know how it is getting the data or if it is even correct,  just that it is there.  and if it isn't there, where along the communication line did it get lost.  BUT, let's say the delivery company loses your regular delivery boy, they can simply change him out and in most cases, it doesn't affect you.  or if prices are cheaper elsewhere for your bananas, they will find it rather than you having to.  it really all comes down to trust and delegation of responsibility.  these issues are why many people do not use this method to obtain their groceries, because it is simpler to make sure the job is done right if you do it yourself.  programming works this way as well.  is it more important to make sure the job is done right by one person? or is it more important to be efficient?

rather than say that any number of tiers is better or worse than any other, i should say that as n becomes larger, design needs to be more intensive.  to take advantage of n-tier, good strong interfaces between your app objects need to be made.  work load needs to be split properly between your programs.  in simple terms 'running an n-tier system is like running a business.  your app is only as strong as the weakest object.  you can make more mistakes faster, but at least you know who is making the mistakes, and replacing any one 'employee' will not hurt  the others unless the means are given for him to do so.'

p.s. i personally like 3-tier achitecture as it seems to provide a balance between the two extremes.

Last 10 Grades Given: A A C C A A B A D A  
"don't develop 3-tier applications...just develop 2-tier"

Nope.  Can't argue FOR it, only against.
Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Just think about it.

2 tier you are modifying and constantly changing the client front end program when changes have to occur.

Why tinker around with the GUI front end when you can modify a middle tier DLL or EXE that contains all of your business logic. When you need to make a change, modify the middle man instead of changing each individual program on the clients.

Take it from experience, 3 tier is definitely the way to go.
Two-tier denotes a rich client with a connection to an RDBMS. (The rich client is one tier and the RDBMS is the other.) Whether the business logic is contained in the client or on the RDBMS (or both) is up to the developer.

The traditional problem with this design is that each client requires a connection to the RDBMS. 100 clients require 100 connections. This can be an expensive price to pay in terms of performance, upgrades and software licensing. (If the number of clients is small, however, the additional development cost of a three-tier design may not be justifiable.)

When the number of clients is or may be large, Microsoft addresses this issue with DCOM (Distributed Component Object Model) and the concept of an application server. An application server delivers functionality to all clients of a given application and typically acts as the business rule components--the middle tier--coordinating access to the data tier--the RDBMS.

Therefore, the three tier design features UI services (on any number of clients or on a Web server for any number of browsers), business services (on an application server) and data services (on the RDBMS). (Conceptually, all of these services may, of course, exist as "logical" services on one or more boxes.)

The benefits of a middle tier are substantial: By coordinating access from multiple clients to the RDBMS, the middle tier can benefit from connection pooling--reusing recently closed database connections. The performance increase of connection pooling can be substantial because acquiring a database connection is typically resource-intensive. The savings on RDBMS licenses may also be substantial.

More importantly, however, the middle tier, with its business logic component(s), is a single point of software upgrades for all clients. (This assumes that the client is designed for a three-tier implementation and is primarily UI code).

Additional benefits can arise when the middle tier offers a level of software isolation from the data tier. (The traditional argument for this implementation is that it facilitates database upgrades and changes. However, in my experience, ADO offers a significant enough level of data abstraction to make RDBMS upgrades/changes relatively painless.) In this case, data-intensive components can be deployed on or near the RDBMS--as stored procedures or data access components. Running business services on one box and data services on another can improve performance and scalability.

You can see the shortcomings of two-tier when many clients are involved: 1. increased cost because 100 clients require 100 RDBMS connections; 2. increased cost because 100 clients require 100 software upgrades; 3. decreased performance because of no connection pooling; 4. possibly decreased performance because of a single box for business and data services.

Lastly, in my experience stored procedures don't always deliver all required business rule functionality. MTS (Microsoft Transaction Server) or COM+ (both positioned as middle-tier technologies) offer substantial value: object pooling (similar to connection pooling but not available to Visual Basic components), security (even down to the method call), asynchronous functionality (with MSMQ or COM+ where a method call can be queued when a network connection to the middle/data tier is unavailable) and other features make strong arguments for a middle tier for enterprise-class applications.

Not every application requires three (or more) tiers. Let the application architects decide what is best!
Bravo, guys.  Two excellent comments, both deserving points.

"pick up some bananas at the grocery store"  I never though programs would be compared to banana shopping.  It made me realize that computer programming has evolved into data management tools rather than data manipulation tasks.  Efficient tools will make your life easier, but are not always better for those one-time tasks (mainly because of the cost factor.)
ROFL, rspahitz,
That's how I teach things.  Aren't analogies great?
But you're very right.  Programming has become bery much so data management.  Even large games right now have large intricate databases managing them and that's why any longer we have data architects and software architects.  As the software gets larger and more complex, the more positions we open up in the industry because any longer, any one part if done incorrectly can hurt the programs that we create.

svfafelAuthor Commented:
tough questions but thanks for the input....
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.