Programming with Microsoft Visual C++.NET 6ed [Electronic resources] نسخه متنی

The COM Infrastructure

Once you get your mind around the concept of interface-based programming, you must implement quite a few details in order to get the class to mix in with the rest of the system. These details often overshadow the fundamental beauty of COM.

To start with, COM classes need a place to live, so you must package them in an EXE or a DLL. In addition, each COM class you write needs an accompanying class object (often referred to as a class factory). The way in which a COM server's class object is exposed will differ depending on how you package the COM class (in a DLL or an EXE). You must also consider the server lifetime. The server should stay in memory for as long as it's needed, and it should go away when it's not needed. To accomplish this, servers maintain global lock counts that indicate the number of objects with extant interface pointers. Finally, well-behaved servers insert the necessary values in the Windows Registry so client software can easily activate them.

We've spent a lot of time looking at MFC in this book. As you saw in Chapter 22, MFC takes care of most of the COM-based details for you. For example, CCmdTarget has an implementation of IUnknown. MFC has even created C++ classes and macros to implement class objects (such as COleObjectFactory, COleTemplateServer, DECLARE_OLE_CREATE, and IMPLEMENT_OLE_CREATE) that will put most of the correct entries into the Registry. MFC has the easiest-to-implement, zippiest version of IDispatch around—all you need is a CCmdTarget object and the Visual Studio .NET environment (specifically, the Add Property Wizard and the Add Method Wizard). And in case OLE drag and drop is your thing, MFC provides a standard implementation of the drag and drop protocol. Finally, MFC remains hands-down the easiest way to write fast, powerful ActiveX controls. (You can write ActiveX controls in Microsoft Visual Basic, but you don't have quite as much flexibility). These are all great features. However, using MFC has a downside.

To get these features, you must buy into MFC 100 percent. That's not necessarily a bad idea, but you should be aware of the cost of entry when you decide to use MFC. MFC is big. It has to be—it's a C++ framework with many capabilities.

As you can see from the examples we've looked at so far, implementing COM classes and making them available to clients involves writing a great deal of code—code that remains the same from one class implementation to another. IUnknown implementations are generally the same for every COM class you encounter—the main difference between them is the interfaces exposed by each class.

Let's take a quick peek at where COM and ATL fit into the big picture.

ActiveX, OLE, and COM

COM is simply the plumbing for a series of higher-level application integration technologies consisting of such items as ActiveX controls and OLE drag and drop. These technologies define protocols based on COM interfaces. You might choose to implement the higher-level features such as drag and drop or controls yourself. However, it makes more sense to let some sort of application framework do the grunt work. Of course, that's why there's MFC.

ActiveX, MFC, and COM

While the pure plumbing of COM is quite interesting by itself (it's simply amazing to see how COM remoting works), the higher-level features are what sell applications. MFC is a huge framework geared toward creating entire Windows-based applications. Inside MFC, you'll find tons of utility classes and a data management/rendering mechanism (the document-view architecture), as well as support for drag and drop, Automation, and ActiveX controls. You probably don't want to develop an OLE drag and drop from scratch; you're much better off using MFC. However, if you need to create a small or medium-size COM-based service, you might want to turn away from MFC so you don't have to include all the baggage that MFC maintains for the higher-level features.

You can use raw C++ to create COM components, but you'll end up spending a good portion of your time hacking out the boilerplate code (IUnknown and class objects, for example). Using MFC to write COM-based applications turns out to be a less painful way of adding the big-ticket items to your application, but it's difficult to write lightweight COM classes in MFC. ATL sits between pure C++ and MFC as a way to implement COM-based software without requiring you to type in the boilerplate code or buy into all of MFC's architecture. ATL is basically a set of C++ templates and other kinds of support for writing COM classes.