Separate COM Data Access Interfaces

[Previous] [Next]

We'd like to conclude this chapter by talking about separate COM interfaces for your data access components. As you did for your main business classes, you can design separate COM interfaces for your data access objects. Figure 12-4 shows an example of that.

In our opinion, it's critical for the life span of main business objects that you expose their functionality through separate COM interfaces only. Doing the same with data access objects isn't as important, at least not the way we figure it.

Here's the reason: A very important mission for main business objects is to be reusable. Many facade objects, belonging to many different user applications, will in time access the main business objects. Even if a new application requires enhanced interfaces to be well served, the main business objects must render the new services without disturbing older clients. This is hardly possible without a clear separation of interfaces from implementation.

Figure 12-4. In this diagram, all the methods of the data access classes are private, reachable only through separate interfaces. Each class supports a generalized interface and could be made to support other ones as well.

With the data access objects, things are different. There are exceptions, but in our architecture a data access object normally has one client only, and it's partitioned from that client, its main business object, which in fact owns it. When only one main business object uses the services of a given data access object, there's never any reason to modify the data access object unless its only client drives the change. They always change together.

Even when a data access object has more than one client, the other clients will always (or should always) be other server objects. The number of clients of a data access object is controllable. If you have to change an interface of such an object, you should also be able to modify its clients as needed without disturbing any user application or facade component.

So why add extra complexity to your design? And, to be truthful, why add the extra overhead? Using a separate interface isn't entirely without a performance cost. When a client wants to use an object through a separate interface, the client must ask the object if it supports the interface by calling its QueryInterface method. ("Doing a QI," as they say at Microsoft.)

In sharp contrast with our firm recommendation that all main business classes be accessed through separate COM interfaces, we can't really find a good reason to add separate interfaces to our data access classes. So we won't introduce them, and our model stays as you see it in Figure 12-5.

Figure 12-5. Now HorseManager objects can connect directly to their data access objects, without going through a separate interface.

As an extra bonus, HorseManager objects are now able to connect to their data access objects just a little bit faster. Since they connect to the default interfaces of these objects, COM doesn't have to call their QueryInterface method to ask whether they support the separate COM interface the HorseManager object wants to connect through. Every COM object supports its default interface, so there's no need to ask.

We just mentioned the advantage of connecting to a default interface. The performance gain is far from huge, so you shouldn't avoid using separate interfaces when they're good for you. You should avoid using them only when they don't give you extra value for that extra call.