The two vertical lines in Figure 1-1 divide the model into the three now well-known tiers:
You can draw several benefits from using the three-tier model instead of the older two-tier model, often called the client/server model. In the two-tier model, clients are constantly connected to the database server, consuming resources such as server memory and processing time. If you consider the fact that a typical user spends much more time working with data locally than fetching from or updating the database, you can see that the two-tier model is wasteful. Clients shouldn't be allowed to hold on to resources when they aren't needed by the client. A large part of this book, spread over several chapters, deals with resource economy and how to achieve it, something that's much easier to do in the three-tier model than in the client/server model.
In Chapter 3, "On Rules and Their Locations," we'll talk about another benefit of the three-tier model. In short, this model allows you to use your favorite language to program your business rules without having to spread the rules around a multitude of client workstations. In the three-tier model, you place your business rules in a central application server, which makes it much easier to maintain and enhance them and also to reuse the same business rules objects in several applications. And that's what Internet applications are all about.
(If you want to read more about application architectures and their respective advantages and disadvantages, you should read Chapter 1 of Mary Kirtland's book Designing Component-Based Applications. You should read the whole book because it's filled with information interesting to anyone reading a book such as the one you hold in your hands right now.)
In the following paragraphs, we describe each of the three tiers of our architecture.
In Figure 1-1, the user services tier has one package only. According to this model, the package can contain different kinds of user services classes. Some of them might be instances of the new webclass in Microsoft Visual Basic 6.0. Others might be ordinary Visual Basic forms, dynamic HTML, or Active Server Pages.
The business services tier contains four packages:
The third tier is the data services tier. In the model shown in Figure 1-1, the tier contains two packages:
This book also touches on the possibility of using data services from ADO MD and thus from the online analytical processing (OLAP) server available with SQL Server 7.0.
You might be interested in accessing other kinds of data services as well: Lotus Notes and Microsoft Exchange Server are two prominent examples.
Many people prefer to divide the business services tier into three subtiers, thus creating a five-tier architecture.
An alternative tier division, using five tiers, would look like this:
One distinct advantage of dividing the business services tier into a facade tier, a main business tier, and a data access tier is this: the facade tier is more closely related to the user application than to the business logic, whereas the main business tier contains the actual business logic. Therefore, you should design the facade tier according to the requirements of a specific user application. You can also modify facade classes as the requirements of this application change over time.
Since the classes of the main business tier implement the business logic rather than any application-specific function, they must be designed for intensive reuse. Therefore, they must be extremely robust, and you shouldn't be allowed to modify them nearly as freely as the facade classes. Otherwise, you might very well make other applications impossible to run.
Thus, your facade tier isolates your user interface objects from the complexities of the main business tier. The facade classes might use the vocabulary of the user application, and they might present much easier programming interfaces than those that exist in the main business tier. Your gain is the added freedom to modify classes, easier development, and much easier maintenance and system enhancements over time. We'll talk about all these subjects at length in Chapter 8.
Likewise, the data access tier isolates the main business tier from the intricacies of the database. Furthermore, if you want to use the transactional services of COM+ and MTS effectively, separating data access from your main business objects is practically a necessity.
For the same reason, you should also use different classes for fetching data from the database and for inserting new or changed information. Separating transactional parts of a component from nontransactional parts is a sound practice, given the way in which both COM+ and MTS manage transactions. Figure 1-2 gives you an example, showing the data access classes package, which contains one fetcher class and one modifier class for the Customer persistent entity class.
Figure 1-2. A Customer class object depends on the services of the related Customer_Fetcher and Customer_Modifier objects.
We'll give you more details pertaining to this explanation in Chapter 12, "Delegating Data Access."
Notice that the data access classes in Figure 1-2 are the results of partitioning the Customer persistent entity class. In an object-oriented design (rather than a component-oriented one), the Customer class would normally not be partitioned in this way. The fetcher and modifier classes would probably not exist in such a design.
For several reasons, all of which will be explained later in this book, we partition persistent entity classes horizontally as follows:
Then we partition the data operations into two separate classes: