Three Kinds of Business Services

[Previous] [Next]

As you can see in Figure 2-12, our architecture defines three kinds of business services:

  • Facade services
  • Main business services
  • Data access services
  • click to view at full size.

    Figure 2-12. Three kinds of business services.

Facade Services

Facade objects, which you create from facade classes, are closely connected to, and in fact belong to, the client application. Their primary purpose is to isolate the client application from the intricacies and complexities of the main business services, thus making the task of client application developers easier.

Main Business Services

Main business services are provided by main business objects. Customer, Order, and Order Item are good examples of main business objects.

This layer is the core of the business services tier, so this is where you'll find the greatest potential for object reuse. You should be very careful when you design components for the main business services tier. Such classes and components should be highly extensible and should be adaptable to new requirements and circumstances. We'll talk more about this later in the book, especially in Chapter 9, "Using Separate COM Interfaces."

Data Access Services

Data access services are provided by data access objects. They isolate the rest of the application from everything that has to do with the database. Their primary purpose is to serve the main business objects with data and to modify the database for them. This aspect of their job often includes data validation responsibilities.

It's often wise to partition data access classes into two separate classes:

  • A class in which the objects mainly fetch data from the database. Since fetching isn't part of transactions, these objects have the MTS or COM+ transactional attribute set to not support transactions.
  • A class in which the objects modify the database. Since these operations are part of (or complete) transactions, such objects' MTS or COM+ transactional attribute is often set to require transactions.

Figure 2-13 shows a partitioned data access class.

click to view at full size.

Figure 2-13. Partition data access classes in two to make the most of the transactional attribute of COM+ and MTS.

Figure 2-14 displays a Rational Rose model. It shows how objects of the Horse class use the HorseFetcher and the HorseTrSrvcs objects to access the database.

Please also notice the padlocks on the left side of all operation names in the Horse class. In Rose, a padlock indicates that the method is private to the Horse objects—that is, it's impossible to call the method from clients of the object. The private methods in the Horse class can be called only from within the Horse object to which they belong.

To expose the methods it implements, a Horse object supports a number of separate COM interfaces. In the diagram, these interfaces are named IHorseImporter, IHorseMaintainer, and IHorseBrowser.

One of the reasons to use separate COM interfaces rather than allow clients to depend directly on the classes is to support the extensibility and maintainability we want for the main business objects. We'll cover this subject in Chapter 9. Right now we'll only point it out to you since it's part of the diagram in Figure 2-14.

click to view at full size.

Figure 2-14. A Rose model, showing how a Horse object delegates data access services to two data access objects: a HorseFetcher object for fetching operations and a HorseTrSrvcs object for modifications of the database.



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