ATL vs. MFC
In a way, ATL is to COM what MFC is to the Windows API. The goal of ATL is to provide a thin but effective wrapper around the most common COM interfaces without sacrificing component performance. Despite this similarity, however, the designs of MFC and ATL differ in several key ways:
MFC contains an interconnected hierarchy of classes, whereas ATL is a set of disjoint templates. This difference means that with ATL you don't pay the size/speed penalty for a given feature unless your component actually uses it.
MFC is linked to a project as a static library or a DLL, but ATL is compiled as source code. Because there are no OBJ files to link to, ATL requires no run-time DLL redistribution.1
MFC supports a single-inheritance model, whereas the functionality of an ATL component depends entirely on the use of multiple inheritance. Specifically, a component that supports several different COM interfaces will inherit from several different associated ATL templates.
Over time, MFC has grown considerably. As the expectations placed on Windows applications have increased, so have the size and feature set of MFC. Although a similar progression is likely as the use of ATL becomes more prevalent, ATL's use of templates rather than regular inheritance will almost assuredly prevent class proliferation.