Components come in all manner of different types. To try to
get an idea of the range of tasks that could be performed using custom-designed
components, it can be useful to categorize components according to their
nature. In this section we'll describe a few of the commonly used categories.
Note that we've only categorized in this way for guidance.
We've intended this as a useful way of understanding what can be done with
components, but nothing more—there are no hard and fast rules about categories,
and they are not mutually exclusive. A given component may fit into more than
one of the categories we describe. If you've used many components in your ASP
development, you'll probably recognize some of these varieties, and may even be
able to name some examples of each. If not, don't worry—you'll have seen plenty
before long!
Some components are of a generalized nature, and designed to
be used in many different environments. Typical examples that display this
behavior are the members of another group that you may well have met before:
the set of ActiveX Data Objects (ADO) components that provide
programmatic access to data stores.
The ADO components ship with all current
Microsoft operating systems and data-aware applications, and they can be used from programming
languages such as Visual Basic, Visual C++ and Visual InterDev. However, they
are equally at home within applications that contain programming or scripting
features, such as Microsoft Office, Windows Script Host (WSH), Internet
Information Server (IIS), and so on. And, of course, we can use them from
ASP—we'll be focusing more closely on ADO and ASP in Chapter 4.
The Brick Calculator component we just saw (and which we'll
be building later in the chapter) is an example of a generalized or universal
component.
Other components are designed specifically for use in a
particular environment, and rely on some of the facilities of that environment
in order to operate. The standard Browser Capabilities component that ships
with ASP, for example, is designed specifically for use within IIS and ASP, and
useless in any other environment. On the other hand, the Progress Bar component
(which is supplied with Windows programming languages like Visual Basic and Visual
C++) is totally unsuitable for use in IIS, as it provides a visual interface
that is designed to provide feedback on a standalone workstation, as opposed to
a web page served across a network or the Internet to a client.
We will come back to
a discussion of client–server and n-tier architecture when we've completed our
'categorization'. But for the moment, if you think about the client as being the machine that makes a request for
the pages, and the server as a different machine where your ASP pages
reside and get processed, with some kind of network in between, you will be
able to follow the descriptions of components.
The Progress Bar component we mentioned above also hints at
a second way of classifying component types: by their support for a visual interface.
Some components are more often described as controls,
and the term is generally used to indicate that a component has some sort of
visible representation that forms a significant part of its operation. The
ActiveX Calendar control that ships with MS Office, the Structured Graphics
control that ships with Internet Explorer 4+, and the FlexGrid control (shown
here) that ships with Visual Basic 6.0 are also examples of components with
visual interfaces.
Because controls are
usually implemented on client machines, as opposed to being run on the server
as part of an ASP script, we will not be covering them in this book.
Business rules
are the rules to which the operation of your component, application or system
(or even your business) must adhere. These rules might involve checking that customers remain within agreed
credit limits, that discounts are applied in a uniform manner, or that a
manufacturing cycle is correctly scheduled. Business rules components are
components that implement this kind of programming logic.
Because business rules components are chiefly concerned with
the internal logic of the application, they often have no visual interface.
However, there are many exceptions to this very general rule.
Transactional Components
Some applications require multiple, separate actions to take
