What is the need of 3 tier architecture or 4 tier architecture

[Guest]

I am working with c# and asp.net in developing web applications, iam using
..netframework 1.1 ,i want to know what is the need of 3-tier or 4-tier
architecture in our application development.what is its part when some body
is using our application.plese give links where i can find the answer.

 

[Bjorn Abelli]

...

I am working with c# and asp.net in developing web applications,
iam using .netframework 1.1 ,i want to know what is the need of
3-tier or 4-tier architecture in our application development.what
is its part when some body is using our application.plese give
links where i can find the answer.

The underlying architecture should be transparent to the user, i.e. he/she
shouldn't be bothered with how the design of the construction is.

The advantages of n-tier architectures are mostly of maintainability for the
developers, where some keywords are "reusability", "pluggable architecture",
etc.

Though, some solutions *need* n-tier of some sort to even work (e.g.
distributed applications).

You wanted links? Here are some to start with...

http://www.microsoft.com/belux/nl/msdn/community/columns/hyatt/ntier1.mspx

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/distapp.asp

// Bjorn A

 

[Kevin Spencer]

Basically, it's all about components. Let's say you have a Windows
application that performs a set of tasks. Now your boss tells you that it
needs to run as a Web Service. If the UI (presentation) logic is mixed up
with the business (task) logic, this is going to be a bear to do. You'll
have to slog through all that code and filter out the business code from the
presentation code. But if you put these into separate components (tiers),
you can easily plug your business code into any type of user interface or
API.

There's more to it, of course, but that's the basic principle. Software
evolves. Build it for evolution, extensibility, scalability.

See the links that Bjorn supplied for more detailed information. But never
forget the basic principles.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
There's a seeker born every minute.
- Dr. "Happy" Harry Cox

 

[BravesCharm]

They are used for scalability too. Think of it like this if you are a
small firm and you use an n-tier environment and choose to use Access
as the backend database. As the company grows you will need an
enterprise level RDBMS like SQL Server. If developed well you will
only need to change the data tier and database management tier (the
RDBMS itself).

Think of each tier as a black box that only has functionality that is
related to what it needs to do. The tiers can just be logical or
physical. In the example above it's move a physical tiers.

Now say you are writing a very small Windows program that uses Access
as a backend database that is on the same computer as your exe. This
one exe does everything; UI logic, business logic and database logic,
you can separate all your logical tiers (UI, Business and Data) into
different objects (Which are scalable when it comes to program design
but not when it comes to architecture design.). When it comes to
performance this would be very very fast but it's not very scalable
because everything is on one computer. Because you divided everything
up logically you can split them into their own physical tier with
little work.

Now you take that exe and keep the UI in one exe and store it on each
user's computer and take the business logic and database logic out of
the UI and put each in its own executable and put them on the same
remote computer. Because you have the UI tier on the user's computer
and business and data tier on a remote computer together everything
becomes much more scalable less efficient because it goes over the
wire.

Now you switch from Access to SQL Server and put SQL Server on its own
computer and all you have to do is change the logic in the data tier.
Now the users wouldn't even know you are switching to a different RDBMS
because the data tier is on a different computer than the UI. Now
because you switched to an enterprise level RDBMS everything is even
more scalable but less efficient because it's going over the wire two
times instead of once now.

Now say the business tier and data tier is getting so much activity
that it's slowing down response time. So now you put the business tier
and data tier on their own servers which becomes even more scalable but
less efficient because now it has to go over the wire 3 times!!

Pretty much what I'm saying is 3-tier or n-tier architecture is more
scalable and can grow with your business. However at the same time
you are giving up some efficiency for scalability because anytime you
have to communicate over the wire or even between executables it's
less efferent but much more scalable because it can grow.

Anyway, hope that helps a bit,
Bravescharm