Network Application Architectures
ASP is a relatively new technology, but people have been building network-based applications for many years. To help us see where our components fit, it's worth taking a look at the options available for network development as whole, since the same considerations will be relevant when it comes to designing our component-based solutions.

Two-Tier (or Client–Server) Systems
Older types of network application were invariably made up of a server (which did the real grunt-work of running the application) and multiple clients (which connected to that server). The clients provided instructions to the server and accessed the results it produced. The clients in this situation are referred to as thin clients, because they do not have to do much work—most of the functionality is hosted on the server.

As time went by and computing power got cheaper, the temptation was for the clients to perform more of the processing work, easing the strain on big expensive servers. When more of this processing work is passed to a client, the typical client application needs to contain all the code needed to process the required tasks. If such a client were accessing a database, for example, the client application would need to be capable of accessing the database and manipulating that data—while the data alone still resides on the server. This is known as a fat client because some of the processing has been passed onto it.

While this relieved the load on the main server, any changes either to the client or to the database then have rippling effects across all client installations. Any changes that need to be made are not just made to the central server; each individual client has to be updated for each change, and potentially several different applications have to be recompiled and updated if data manipulation and access code is shared between them.

To help reduce the maintenance of 2-tier systems, database views and stored procedures can be used. Both provide an elementary level of indirection that can sometimes help reduce the impact of database changes on client code. However, neither works very well in the case of distributed, heterogeneous databases; unless the same provider (SQL Server, for example) is used for each database engine, and inter-database interoperation is non-existent. This means that stored procedures have to be duplicated, which can be a potential concern for enterprise applications.

As computers spread into more areas of the workplace, the demands on computer-based applications rose rapidly. These applications are often referred to as enterprise applications, and incorporate many servers and data stores. They tend to be organic in that they are always growing, and tend to be difficult to design and to maintain.

To help programmers work with programs and data spanning increasing areas, it made sense to divide up the application into layers or tiers. The important thing to remember when talking about tiers in an application is that they can be logical or physical.

A physical tier is one that actually resides in a distinct physical place, while logical tiers are more conceptual way of thinking. Logical tiers help us plan and view the different parts of an application, removed from concerns about where they reside physically.

Thinking about architecture changed, along with the expansion of networked applications, to three-tier models. We shall take a quick look at this next so that you can understand where we are using our components (you may also have heard of n-tier applications, which are an extension of the three-tier model, and which we will come back to in Chapter 5).

Three-Tier Applications
You can view the client–server model as being a 2-tier application structure. This is extended in the three-tier model by the addition of a middle layer that sits between the client and the data sources. The three physical tiers break down as follows:

q The client tier is the front-end tool with which the end user interacts. It may take the form of any type of user interface, such as a Visual Basic application, or (increasingly commonly) a web browser. In ASP applications, the client tier usually takes the form of a web browser.

q The middle tier (also referred to as the business tier) represents most of the logic that makes the application functional. In the case of ASP this is where our ASP pages reside, upon the web server.

q The data tier represents the storage mechanism used to hold persistent data. This could be a relational database, text-based file, directory, mail server etc.

The Client Tier
The client browser requests an ASP page from the server, and is presented with an HTML form for entering data about the size of wall and brick. The user then clicks on the Calculate button, which sends the form details to the web server. Later, the client receives the response from the web server and displays the results of the calculation.

The Middle Tier
This is where our web server resides, holding (amongst other things) the ASP pages and our components. When the client requests the form, the web server creates it as HTML using WroxBloxForm.asp. When the user clicks Calculate on the client end, the values are sent to WroxBloxResult.asp. WroxBloxResult.asp creates an instance of the BrickCalculator component, also on the middle tier, which uses the passed parameter values to calculate the number of bricks required, and returns the result to the page. The page then writes this back to the client.

In this case, all of the logic of the application, creating the component, and calculating the number of bricks required, goes on in the middle tier.

The Data Tier
OK, so our example doesn't use the data tier. However, if we needed to collect or store any persistent data in a database, such data would reside in this tier. Busy sites will gain great performance advantages from actually having the database residing on a separate physical server, because databases typically require a lot of system resources. During the design phase, this is not always possible—but the notion of a logical data tier still exists, whether or not the database resides on a separate server.