Development Frameworks (ATL role)

Using Visual C++ 5.0 or 6.0, we have three different ways to develop COM components. We can use the manual method, the Microsoft foundation classes (MFC), or ATL.

The previous modules partially demonstrated the manual method, which is basically working without a development framework. Instead of a development framework, we write code that:

1. Sets up our C++ implementation classes for class factories, COM objects, and interfaces
2. Implements required in-process functions such as DllGetClassObject and DllRegisterServer

This gives us the most control, but also takes a lot of development effort--i.e., we spend much time working on repetitive development tasks such as registration, class factory support, and IUnknown code. Development frameworks like MFC and ATL provide built-in Data Driven implementations of these tasks.

MFC provides outstanding support for developing Windows applications and DLLs. MFC is especially strong when it comes to developing user interface components. Several different types of views (for example, classes derived from CView) make it very easy to develop sophisticated user interfaces. The art of using MFC effectively involves understanding the code generated by the Visual C++ AppWizard, the MFC class hierarchy, how to use the Class Wizard, and MS-Windows programming basics. For GUI-based COM components, MFC is a good choice.

ATL provides an extensible, template-based class hierarchy. Although ATL does provide some user interface support, its main goal is to support development of lightweight COM components. ATL is an excellent choice for 1) non-visual COM components or 2) COM components with minimal user interface requirements. The Active Template Library (ATL) is a set of template-based C++ classes that let you create small, fast Component Object Model (COM) objects. It has special support for key COM features, including stock implementations, dual interfaces, standard COM enumerator interfaces, connection points, tear-off interfaces, and ActiveX controls. If you do a lot of ATL programming, you will want to learn more about COM and .NET attributes, which is designed to simplify COM programming.

Many of the tasks we perform in COM are the same for every server and object. For example, to register COM objects, we always make the HKEY_CLASSES_ROOT\CLSID\{ clsid } entries. To implement IClassFactory::CreateInstance, we always create an instance of the C++ class that implements a COM object. To implement IUnknown::QueryInterface, we always check the requested IID and (if it is supported) place an interface pointer in the output parameter and call AddRef on the pointer, and so on.
The only differences in these tasks between different projects are the CLSIDs, the IIDs, and the names of the C++ classes we use. Development frameworks such as MFC and ATL provide generic implementations of IUnknown, IClassFactory, and required in-process DLL functions (i.e., DllGetClassObject, DllRegisterServer). These implementations are data driven. We tell the framework the name of our C++ implementation classes for COM objects/interfaces, object CLSIDs, and IIDs. Using this data, the framework can carry out the requested tasks, for example, implement CreateInstance or IUnknown. As part of the development process, developers use tools associated with the framework to create their C++ classes and provide the framework the data it needs.

MFC is not specifically designed to support COM. Although adding support for COM objects is not hard, using MFC also involves understanding and using the document/view architecture. This is far more functionality than we need or often want.

ATL is specifically designed to support development of COM objects and servers. It provides a lightweight class hierarchy that adds little extra overhead. Additionally, Visual C++ provides the ATL COM-Wizard to generate skeleton COM servers and class creation tools to support adding COM objects and methods.
ATL is an application framework, not a class library. Unlike a class library, an application framework defines and controls the structure of an application. You add application-specific functionality by defining a class at a specific location in the class hierarchy. For example, your class must inherit from one or more classes in the framework. Additionally, in an application framework, you often override specified functions. Framework code will call into your code directly or via polymorphism (i.e., virtual functions that you override) to hook your code into the framework.