Tiers and Classes

[Previous] [Next]

According to our architecture, we need at least the following modules:

In the user services tier

• A GUI class. We'll use a simple Microsoft Visual Basic form, at least initially. We've named it frmHorseMaint.

In the business services tier, which is partitioned into three kinds of services

The facade services:

• A facade class, shielding the GUI from the possible complexities and intricacies of the inner parts of the server application. Its name is fcdHorseMaint.

The main business services:

• An entity class for access to record-oriented data and functionality. Its name is Horse.
• A set (or collection) class for access to set-oriented data and functionality. We've named it Horses.

The data access services:

• A class for fetching operations. We've named it HorseFetcher, and its purpose is to serve the Horses class as well as the Horse class.
• A class for transactional operations, such as insertions, updates, and deletions. Its name is HorseTrSrvcs, and like the HorseFetcher class, it will serve both the Horses and the Horse classes.

A Tier Diagram

We've also diagrammed an overview of our model using Rational Rose and displayed it in Figure 5-1. (The bulleted list describes our model in detail.) We could have just as easily used Microsoft Visual Modeler to produce the diagram.

Figure 5-1. An overview of the logical packages (logical parts of the application) of the maintenance portion of our sample horse racing application.

• The user services tier has a package of forms. The forms in this package will depend on objects in the Facades package for business services and the ADOR package for data services. More on the ADOR package shortly.

Please note that this model assumes transport of data using ADO recordsets. Later in this book, beginning with Chapter 20, "An XML Overview," we'll introduce an alternative medium for transportation, namely Extensible Markup Language (XML). For the time being, however, we're sticking to ADO recordsets.

The facade objects are the only elements of the architecture that the forms can access and communicate with. The rest of the application, which consists of the main business objects, the data access objects, and the database, is invisible to the forms.

• The business services tier has three packages:

• The Facades package, which includes facade classes.¹ They'll mainly delegate their services to objects in the Main Business package, and they'll depend on objects in the ADOR package for data transportation services and for any state keeping needed.
• The Main Business package, which includes entity objects as well as set-oriented objects. These objects will perform services for the facades, and they'll depend on objects in the Data Access package for data access operations. They'll also depend on objects in the ADOR package for data transportation services and possibly also for the keeping of state.
• The Data Access package, which includes objects that fetch information from the database and other objects that will modify the database. These objects will perform services for objects in the Main Business package, and they'll depend on the full ADODB package because they must, of course, be able to access the database.

• The data services tier also has three packages:

• The ADODB package, which contains all the objects in ADO and gives full access to OLE DB and thus to the database.
• The ADOR package, which is a lightweight version of ADODB and contains only ADO recordsets. Only objects in the Data Access package will need the full services of ADO. All other objects will do fine with the lighter ADOR package and by so doing will conserve resources. And as we mentioned in Chapter 1, "Planning for a New Architecture," these other objects will be able to drop ADO altogether if they receive their data as XML documents instead.
• The Microsoft SQL Server package, which, of course, represents the database itself.

What about COM+ and MTS?

You might wonder why neither COM+ nor Microsoft Transaction Server (MTS) is included in the diagram shown in Figure 5-1, especially since ADOR, ADODB, and SQL Server are. The answer is this: we're keeping them on hold. We will include the services of these technologies, but not until Chapter 14, "Using Microsoft Transaction Server."