A Framework

[Previous] [Next]

Now we have it all; at least we have what's needed to manage horse data. We've designed and at least partially implemented the following classes:

• A dynamic HTML (DHTML) page prototype, which in time will evolve into the GUI for maintaining horse data. In a real project, we would have several other GUI prototypes as well.
• A facade class, which at this moment has everything needed to act as an interface between the GUI application and the inner parts of the server. In a real project, we would have several other facade classes as well.
• A main business class—HorseManager—that exposes its capabilities through a number of separate interfaces. We also have two other main business classes—TrainerManager and CountryManager—even if they implement only the IViewerADO interface at the moment. In a real project, we would have several other main business classes and probably a multitude of other interfaces as well.
• Two data access classes—one for fetching operations on the Horses table in the database and another for modifying operations on the same table. In a real project, we would have several other pairs of data access classes as well.

A structure such as the one we've just created is dead easy to keep in order. After all, it consists of a handful of objects only. In a real project, though, the objects would be multiplied and then multiplied again, and things wouldn't be quite as easy. To make things easier, you need a framework for organizing your classes. You should build such a framework on the three-tier services model, adding your own UML packages to that model. Figure 18-18 shows such a framework, organized according to the needs of our horse racing project.

Figure 18-18. A multitier framework, based on the three-tier services model.

It's particularly interesting to notice that both the user services and the facade packages have names that refer to four of the actors we defined during use case analysis. For example, the Customer User Services package contains forms and pages that together constitute the customer's user interface to the application. It's easy to export this package from the model, giving the exported package to one GUI developer or a GUI developer team and expecting them to create the customer's user interface.

You can do the same with the other actors' user services packages. The different GUI developers and GUI developer teams responsible for the respective packages don't even have to confer. It's not only perfectly all right but also probably preferable to create one user application for each actor. There's normally no need for a customer to have access to the administrator's application and vice versa.

It's also interesting to see that each actor has one facade package, containing the facade classes that give this actor access to the main functionality of the business services provided by the application. Each facade package is a good candidate for installment in its own MTS package or COM+ application. As we explained in the section "Permission Roles in COM+ and MTS" in Chapter 9, "Using Separate COM Interfaces," using MTS or COM+ security roles for such a package or application makes it easy to secure.

The main business objects, main business interfaces, and data access objects are organized differently. None of them belong to any particular facade or actor; they belong to the business itself and are meant to be reused by the different facades of this application and, in time, facades of other applications. The same, naturally, goes for the IIS/ASP Objects package, which contains the typical objects of Microsoft Internet Information Service (IIS) and Active Server Pages (ASP).