ASP.NET 3.5 Application Architecture and Design: Build robust, scalable ASP.NET applications quickly and easily.

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:

Firstly, we will study the classic inline style of coding, which was the only option available during the good old ASP 3.0 days. This was a mix of interpreted ASP scripts and HTML code. In terms of architecture, there was not much flexibility, although developers used classes to bring some object oriented flavor to the projects, but these were not pure OO classes. Core features such as inheritance were not supported. Moreover, there was lot of effort involved in coding these classes, so most developers preferred to mix coding that was much faster in terms of development time. At a high level, an ASP project configuration would usually follow the given diagram:

In this diagram, we have ASP script files in the web server directory being processed by ASP ISAPI (Internet Server Application Programming Interface) DLL in IIS and rendered in the client browser. ISAPI DLL is a part of IIS itself, and not a separate process such as the ASP.NET runtime engine.

Here...

In the above classic ASP style example, we noticed that the code and HTML were separated but still present on the same ASPX page. ASP.NET introduced further separation using the principle of code-behind classes, by pulling all of the code out from the ASPX into a separate class and compiling it to a separate DLL. (Note that a DLL is not really required either, if the developer wishes to deploy the code-behind into the web directory. ASP.NET will compile the code "Just-In-Time" into a temporary DLL, so "pre-compiling into a DLL" is not required either.) This allowed the programmers to debug their applications more efficiently and also introduced further loose coupling in the UI layer, introducing another layer into the above 1-tier architecture.

Here is a diagrammatic representation of the above style:

The partial class compilation model was introduced with ASP.NET 2.0. Partial classes help us break up a main class into sibling classes, which can be merged...

With further refinements to ASP.NET 2.0, Microsoft has added many out-of-the-box controls (apart from the standard web control library). Some of the most useful controls are Data Source Controls, complimenting the feature-rich web server controls such as the GridView and the DetailsView. These controls have made it possible to create applications without writing even a single line of data access code. Now it is possible to create web applications within a short timespan, doing away with many lines of routine data access code.

With Data Source Controls, we can use SQL queries as well as stored procedures, and write custom code too. Although we won't go deep into the details of how to use controls, as there are many freely-available online resources and articles on this subject, we will see how using these controls affects the overall architecture, when to use them and what their disadvantages are.

In this chapter, we examined how web applications inherently follow a 3-tier client-server model, and how a 1-tier architecture can be used for simple applications in ASP.NET. Then we learned how we can logically partition this basic 1-tier 1-layer architectural style into two sub-layers, using code-behind files. We also studied how declarative code-less programming using new Data Source Controls follows a single-layer style.

In a nutshell: