Default N-Tier Nature of Web Applications
When working with web applications, a very important concept to grasp is that by its very own nature each web application is distributed and is inherently 2-tier by default (or 3-tier if we include the database as a separate tier). Therefore, it is not possible to have a single-tier (or 1-tier) architecture at all, when dealing with web applications. And as we saw in the last chapter, if we include a database and client browser in our system, then we already have a basic 3-tier application structure.
Let's understand this concept in detail with a sample configuration for a simple ASP.NET web application:
- Web Server: A machine running a web server such as IIS, handling all HTTP requests and passing them onto the ASP.NET runtime process. The deployed project files (
ASPX, ASCX, DLLsetc) are published on this server. - Database Server: This will be the physical database such as SQL Server, Oracle and so on. It can be on the same machine as the web server or on a separate machine.
- Client Browser: This will be the browser that the client is running to view the web application. The browser runs and uses client machine resources.
The example shows a deployment scenario, where we have the web application deployed on machine A, which is running IIS.
This is how the configuration will look:
Based on the above diagram, we have a distributed 3-tier architecture with the following tiers:
- Presentation Tier: This is the client browser displaying rendered HTML from the web server.
- Application Tier: This is machine A, which has the web server running along with the application's UI, business logic, and data access code, all deployed together on the same machine.
- Data Tier: This is the database running on machine B. We can also call this a Data Layer.
An important point to note is that in ASP.NET web applications, the presentation tier (browser) is different from the GUI (which is actually the ASPX/ASCX application frontend).
In this chapter, in order to simplify the understanding of application architecture, we will be considering tiers from the application's stand point and therefore ignoring the database (data tier) and client browser (presentation tier). So a single ASP.NET web application, in monolithic terms, is 1-tier. We will see how to break this 1-tier 1-layer web application further into layers and tiers, understanding and analyzing the needs and effects of each step.
Usually, it takes a lot of experience working with different types of architectures to become familiar with the advantages and disadvantages of each approach. A developer who has worked only in 3-tier (or higher) applications may find it very difficult to conceptualize and adapt to a 2-tier approach even though it may be more suitable for his project. He will feel more comfortable in the n-tier based architecture even when it is not required. That is why it is very important to study the 1-tier and 2-tier designs and analyze their pros and cons, to appreciate the usefulness and the real need of breaking it further into multiple tiers and layers.
In this chapter, we will focus on how to break the monolithic default ASP.NET architecture into multiple layers and tiers and see when and where to use this style. We will also see how we can logically break the 2-tier style into different layers for more flexibility and better code management.