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
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
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.
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
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:
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.
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
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
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.