Three Tiers -- Or Five If You Like

[Previous] [Next]

The two vertical lines in Figure 1-1 divide the model into the three now well-known tiers:

  • User services
  • Business services
  • Data services

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.

User Services

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.

Business Services

The business services tier contains four packages:

  • The first package contains facade classes. The purpose of these classes is to act as facades in front of the "real" business objects the user interface needs to communicate with. In Chapter 5, "Modeling the First Business Tier," we'll show you why facade classes are important and how they can help.
  • The second package contains persistent entity classes. It holds ordinary object-oriented business classes. Objects belonging to these classes have to save their data to a database before they allow themselves to be deactivated. Customer, Product, and Order are good examples of these types of classes.
  • The third package contains classes—set management classes—that are responsible for set-oriented operations. They might return recordsets and even handle set-oriented updates. They might also be stateful, managing collections of persistent entity classes, even if that should be considered optional. After all, stateful objects don't scale nearly as well as stateless ones do. We'll talk more about statefulness and statelessness in Chapter 8, "Designing the Main Business Tier." Later in this book, we'll combine the second and third packages into one. We'll modify them in other ways as well to increase their scalability.
  • The fourth package contains data access classes. The classes of this package build SQL statements and stored procedure calls. These classes, and they alone, communicate (via ADO or the multidimensional version of ADO, ADO MD) with the database. This package also manages transactions. You should normally not allow classes other than your data access classes to support or require transactions. Classes in other packages should be free of that obligation.

Data Services

The third tier is the data services tier. In the model shown in Figure 1-1, the tier contains two packages:

  • An ADODB package that contains all the classes in ADO—Microsoft's strategic universal data library.
  • A database that could be anything you can access via OLE DB or ODBC. In the examples in this book, the database is Microsoft SQL Server, but it could just as well be an Oracle, an Informix, or a DB2 database.

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.

Five Rather Than Three Tiers

Many people prefer to divide the business services tier into three subtiers, thus creating a five-tier architecture.

  • The first of the three new tiers is the facade tier or, if you prefer, the application tier or the workflow tier.
  • The second is the main business tier.
  • The third is the data access tier.

An alternative tier division, using five tiers, would look like this:

  • User services
  • Business services
    • Facade services
    • Main business services
    • Data access services

  • Data services

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

Partitioned objects

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:

  • The original class—in this case, the Customer class
  • A separate class for direct operations against the data store

Then we partition the data operations into two separate classes:

  • One class that performs fetching operations, that is, operations that aren't involved in transactions (for example, Customer_Fetcher)
  • One class that performs modifications to the data store, that is, operations that involve transactions (for example, Customer_Modifier)


Designing for scalability with Microsoft Windows DNA
Designing for Scalability with Microsoft Windows DNA (DV-MPS Designing)
ISBN: 0735609683
EAN: 2147483647
Year: 2000
Pages: 133

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net