COMments

[Previous] [Next]

Using the Class Events technique is the native language support solution for an Event Service design pattern implementation in Visual Basic. It's definitely one of those features that lives up to the Visual Basic reputation of being unbelievably easy to implement while providing extremely powerful results. There is one huge disclaimer however. You must be aware of the underlying technology implemented by Visual Basic. Under the hood, this design pattern is implemented using Microsoft's COM connectable object technology. (Full documentation of this technology is available in the Microsoft Developer Network (MSDN) library.) Registering a subscriber requires a minimum of three interface method calls. Using WithEvents in-process and in the same threading apartment (see Chapter 3 for a complete discussion on threading) has negligible performance implications. Referencing objects out-of-process using WithEvents is costly, however, and should be avoided by all means.

Another subtle but important aspect of the Class Events approach is that the notification process is opaque. The only action that the event source class object can perform in Visual Basic is to raise an event by invoking the reserved word RaiseEvent and specifying the name of the event. When multiple sub-scriber class objects are registered to receive events via the WithEvents reserved word, controlling or determining the order of notification is impossible. You therefore can't set priority notifications. Also, there is no way to break the successive calls to all subscriber class objects. For example, you might want an event to bubble up through a list of ordered subscribers. Each subscriber can be empowered to cancel the event and prevent it from traveling to other subscribers. Finally, event publication is synchronous in COM connectable object technology. An event can easily get hung up in a subscriber, preventing the event channel from carrying out the publication to other subscribers.

A better alternative to using the Class Events method is the interface-based approach. With this approach, you build your own event channel, thereby avoiding the use of the COM connectable object technology. To this end, subscriber registration can be accomplished with a single interface method call; you're in complete control of the notification order; and your event channel can notify subscribers asynchronously. You are limited only by your design decisions.

It wouldn't be fair if I didn't mention the fact that Microsoft has realized that the COM connectable object technology is not a truly robust event service. In response, Microsoft has developed a whole new event service running as an operating system service in Windows 2000 as part of the Microsoft COM+ technology package. Consider the service to be an event channel that now supports most of the features you would have to build yourself using the interface-based technique.