asked on

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

ameba

Last 10 Grades Given: A A C C A A B A D A

rspahitz

"don't develop 3-tier applications...just develop 2-tier"

Nope. Can't argue FOR it, only against.

Bob Butcher

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.

uschmitz

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!

ASKER CERTIFIED SOLUTION

renaissance

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

rspahitz

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.)

renaissance

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.

Renaissance

cjswimmer

svfafel

ASKER

tough questions but thanks for the input....