C# .NET - Difference Between 2 tier,3tier,4tier

Asked By sagar yamsani on 13-Nov-11 11:59 PM
I want to know the clear difference between 2-tier,3-tier,4-tier architectures in .Net,Please give me the clear illustrations
s j replied to sagar yamsani on 14-Nov-11 12:04 AM


1-Tier : Single Host

The good ol' days where people thought they only needed one computer for the whole organisation meant that you physically had one tier. Logically the functions could well have been segregated, but in most cases this scheme would be considered one tier. Using Microsoft Access on your own unconnected desktop, or a dumb-terminal based system could well be considered 1 Tier also.

2-Tier : Client Server

Client Server was a major buzzword in the early 90's, taking initially dumb terminal applications and giving them a fancy windows-like front end, using PCs with terminal emulators which presented pretty GUIs or later Visual Basic etc front-ends. This situation varies along a spectrum of intelligent client/dumb server to thin client/powerful server. A web browser talking to a web server is an example of a client talking to a server. Here there is presentation logic (presentation tier) happening at the client, and data/file access (data access tierand logic happening at the server.

3-Tier : Client/Presentation Layer, Business Logic/Process Layer and Data Layer

The most popular architecture on the web currently, mostly taking the form of web browser processing client side presentation in the form of HTML/DHTML, etc, the web server using some scripting language (our fave ASP) and the database server (SQL Server for example) serving up the data. Various solutions move the bulk of the work around, beginners to ASP often have the ASP doing all the work with the database being little more than a data store. More advanced solutions could have the client doing loads of work with browser based scripting and XML data islands, or at the other end of the spectrum the database powering the whole thing with stored procedures.

N-Tier : The above and more

So, finally, we get to N-Tier, and N-Tier is basically "A number of Tiers", usually an expanded model of 3-Tier. If we take the 3-Tier example above, we have a crude (but workable) starting point, but if we need more performance or scalability (which we inevitably do) there needs to be more refinement.

A good place to start is to move logic out of the scripting language. Scripting languages (up .NET anyway) are not "proper" languages and are usually more solutions for fancy templating, that is presentation layer stuff and glue for components. In an ASP scenario, this would mean the ASP keeps everything talking to everything else, presenting the results from COM components methods calculations, which form the business logic Tier. The COM components could be split into "Process" and "Data Access", the data components knowing how to talk to the stored procedures and the process components doing actions on the data. Once you have a Data Access Tier you could consider if this function should be further split, or perhaps distributed using DCOM or Message Queues.

Suchit shah replied to sagar yamsani on 14-Nov-11 12:05 AM
2-tier - also called client/server applications which consist of two separate applications, one server
application (typically a database server like Oracle, MSSQL or any other standalone database) and a client application. suppose you want to have many different clients for front-end would be unwise to copy all the business logic (all the rules of your application) to each client app. so its better to create a middle layer containing the business logic, and then let the clients talk with this middle
layer. Thus the clients can relatively easily be changed for other types of clients, without need for remembering. how was the business logic put together.

3-tier architeture where one tier is the backend database engine, one is the front end client and one is just in between them, also named the application server or business logic node.Its uses mainly Load balancing and Fault tolerance.

A good example of a tier follows the jerarquical model where responsibilities are carefully addressed to the appropriate people. For example, a common business has Commercial, Marketing, Systems, Development and Test department (for example), which represent tiers of business. That way, responsibilities are clear, Development provides the product, Testing test it, Marketing promote it and Commercial sell it, all that while systems keep the infrastructure running (is just an example).

This metaphor was first approached with the 3-tier model, where three tiers are identified. Usually this tiers are Database Abstraction Layer, which is in charge of communication and abstraction over the database, Business Rules Layer, which holds the rules that describe the business process and User Interface Layer which abstracts the interaction of the user with the system.

That way, we have roles for the responsibilities of each layer, so that if the user needs to interact with the system he will communicate with one layer, not mess up across the hole system.

N-tier represent an evolution of the former concept by using more tiers to address specific needs. Usually user interface layer and database abstraction layer are left untouched, as their roles are pretty clear while business rules layer is further refined.

For that, we always take into account the characteristics of the problem as well as the features we want to provide now and in the future. For example, if an application will need to work with smart clients or its foreseen to work with smart clients then business layer is usually divided into a proxy layer and a back-end layer, the first routing the calls where they should go.

In the end, what's important is the concept of abstracting responsibilities among different layers, and centralizing all related operations from a semantic view in the same place.

Note that, in addition, n-tier architecture allows for distribution of those "responsibilities" among developers. That way, a given team can have responsibility over the Database Abstraction Layer while other team works on the Proxy Layer and another one works on the Graphics Abstraction Layer. When a member of a team needs to access the database he look up the DAL documentation and use one of the facilities provided or ask the DAL team to provide with the functionality he needs, so that he does not address directly the database but through the people that better known the design and intricacies of the database itself.

The Three Tier Model

Business applications today all access data as part of their core functionality. As relational database servers gained in popularity 20 years ago, the industry moved from a one tier (mainframe) model to a client server model where we had a client performing the presentation logic and most of the business logic and the server with the data storage and some business logic in the form of stored queries. By the early 1990s this model broke down due to high maintenance costs and a lack of a separation of concerns and we moved to a three-tier architecture as shown in Figure 1.

Figure 1. A 3-tier architecture. (Source: Wikipedia)


A three-tier architecture enforces a logical (and sometimes physical) separation of three major concerns:

  • Presentation-the user interface components.
  • Business Logic-processes commands requested by the users, makes logical decisions such as calculations and computations. Retrieves data from the data tier.
  • Data storage and retrieval-storage and retrieval of data for the system and passes the data to the business layer for processing and ultimate rendering to the user by the presentation tier. In theory this tier can be file storage, XML, or a relational database, however, a relational database is by far the most common usage.

The goal of separating the logic is twofold. First there is a performance gain by having the database server focus only on database storage and retrieval. Specific hardware and topologies (such as RAID) are used for database storage and access that are different from an “application server” or middle tier of business objects and logic. In addition with powerful client machines it made sense to push UI processing down to the client.

Second was the separation of concerns principle. By separating out the logic of a system, you can easier maintain the overall system, reuse code, and keep associated logic and code in one location.

The n-Tier Model

By the later 1990s, the industry extended the three-tier model to a multi-tier approach. The model is logically the same but what forced it to change was that the Internet became an important part of many applications.

Web services (and later REST data) have become more integrated into applications. As a consequence the data tier usually became split into a data storage tier (database server) and a data access layer or tier (DAL). In very sophisticated systems an additional wrapper tier is added to unify data access to both databases and web services. Web browsers were far less powerful than a traditional client tier application and the user interface logic became split across the browser with JavaScript and the server with web server UI rendering logic such as ASP or PHP.

Tiers started to get blurred ever further with the addition of stored procedures by all the major database vendors and open source databases. This spread some business logic from the business tier to the database tier, creating tiers within tiers. For example a business component inside of Microsoft Transaction Server (an Object Request Broker or ORB) is a logical business tier; however, it most likely calls a stored procedure, which is a logical business tier inside of the database tier.

As tiers got more blurred due to the Internet, technology innovations and services, the three-tier model evolved to the n-tier model as shown in an example in Figure 2.

Figure 2. An n-tier architecture. (Source MS Patterns and Practices)


The Problem with the n-Tier Architecture

The n-tier architecture has been very successful. Most sophisticated applications today use some form of the n-tier model. Years ago to support this model, enterprises would have as many as five different job titles around the data centric business application. The job titles were:

  • Data Modeler
  • Database Administrator
  • SQL Programmer
  • Object Modeler
  • Application Developer

The data modeler would design the physical tables and relationships. The DBA would create the tables, maintain them and come up with an index and physical disk strategy and maintenance plan. The object modeler would build and object model (or API) and map behaviors to methods. The SQL programmer would work with the object modeler and application developer and write stored procedures and views under the guidance of the DBA. The application developer would use the object model components and would “glue” the application together.

That was then. While some large organizations still develop this way the advent of RAD tools in the late 1990s, the agile/XP movement in the early part of this decade, the .com boom, and ultimately offshoring and budget cuts, most firms do not organize this way anymore. Many smaller shops have one “database guy” (if at all) and one “code guy.” Some only have one person in total. Companies then push most of the modeling and procedure creation to the “db guy” and application developer.

With budget cuts, smaller teams, and the rise of cross-function teams there are not enough “database guys” to go around. Developers complain that they spend over 30% of an application’s code on database access code. This only exacerbates the object-relational impedance mismatch.

2-tier architecture
In 2-tier, the application logic is either buried inside the User Interface on the client or within the database on the server (or both). With two tier client/server architectures (see Two Tier Software Architectures), the user system interface is usually located in the user's desktop environment and the database management services are usually in a server that is a more powerful machine that services many clients. Processing management is split between the user system interface environment and the database management server environment. The database management server provides stored procedures and triggers

3-tier architecture
In 3-tier, the application logic (or) process lives in the middle-tier, it is separated from the data and the user interface. 3-tier systems are more scalable, robust and flexible. In addition, they can integrate data from multiple sources. In the three tier architecture, a middle tier was added between the user system interface client environment and the database management server environment. There are a variety of ways of implementing this middle tier, such as transaction processing monitors, message servers, or application servers. The middle tier can perform queuing, application execution, and database staging. For example, if the middle tier provides queuing, the client can deliver its request to the middle layer and disengage because the middle tier will access the data and return the answer to the client. In addition the middle layer adds scheduling and prioritization for work in progress. The three tier client/server architecture has been shown to improve performance for groups with a large number of users (in the thousands) and improves flexibility when compared to the two tier approach. Flexibility in partitioning can be a simple as "dragging and dropping" application code modules onto different computers in some three tier architectures. A limitation with three tier architectures is that the development environment is reportedly more difficult to use than the visually-oriented development of two tier applications. The most basic type of three tier architecture has a middle layer consisting of Transaction Processing (TP) monitor technology. The TP monitor technology is a type of message queuing, transaction scheduling, and prioritization service where the client connects to the TP monitor (middle tier) instead of the database server. The transaction is accepted by the monitor, which queues it and then takes responsibility for managing it to completion, thus freeing up the client.

4-tier Architecture
In a 4-tier architecture, all of the data storage and retrieval processes are logically and usually physically located on a single tier. A 4-tier architecture allows an unlimited number of programs to run simultaneously, send information to one another, use different protocols to communicate, and interact concurrently. This allows for a much more powerful application, providing many different services to many different clients. In this application we will have following 4-Tiers
1. Business Object [BO]
2. Business Access Layer [BAL]
3. Data Access Layer [DAL]
4. UI (4-Tier) folder [UI]

Jitendra Faye replied to sagar yamsani on 14-Nov-11 12:14 AM
Reference from-

  • Tier 1 = Non-redundant capacity components (single uplink and servers).
  • Tier 2 = Tier 1 + Redundant capacity components.
  • Tier 3 = Tier 1 + Tier 2 + Dual-powered equipments and multiple uplinks.
  • Tier 4 = Tier 1 + Tier 2 + Tier 3 + all components are fully fault-tolerant including uplinks, storage, chillers, HVAC systems, servers etc. Everything is dual-powered.
Jitendra Faye replied to sagar yamsani on 14-Nov-11 12:15 AM
Follow these also-

a. 1 tier application:All the processing is done on one machines and numbr of clients are attached to this machine (mainframe applications)

b. 2 tier application: Clients and data base on different machines.Clinets are thich clinets i.e.  processing is done at client side.Application layer is on Clients.

c. 3 tier application.Client are partially thick.Apart from that there are two more layers application layer and database layer.

d. 4 tier application: Some clients may be totally non thick clients some cliints may be partally thick and further there are 3 layers web layer, application layer and database layer.