Acho que a resposta à sua pergunta é principalmente histórica, se você olhar para trás e ver como as duas bibliotecas se originaram e evoluíram ao longo do tempo.
A resposta curta é, se você não está fazendo nada "extravagante", use ATL. É ótimo para interfaces de usuário simples com COM incluído.
A longa resposta: o MFC foi criado no início dos anos 90 para testar essa nova linguagem chamada C ++ e aplicá-la ao Windows. Ele disponibilizou recursos semelhantes aos do Office para a comunidade de desenvolvimento quando o sistema operacional ainda não os tinha.
[Editar enfeite: eu não trabalhei na Microsoft, então não sei se o Office já foi construído no MFC, mas acho que a resposta é não. De volta ao Win 3.1, Win 95 dias, a equipe de IU do Office inventaria novos controles, empacotaria-os em bibliotecas e, em seguida, as equipes do Windows e MFC incorporariam wrappers e API a esses controles com dlls redistribuíveis. Eu acho que houve um pouco de colaboração e compartilhamento de código entre essas equipes. Eventualmente, esses controles chegariam ao sistema operacional de base em service packs ou na próxima versão do Windows. Esse padrão continuou com a Faixa de Opções do Office, que foi adicionada ao Windows como um componente complementar bem depois do lançamento do Office e agora faz parte do sistema operacional Windows.]
Naquela época, a biblioteca era bastante primitiva, tanto por causa da linguagem C ++ e do compilador serem novos, quanto pela Microsoft construí-la ao longo do tempo conforme o Office evoluía.
Por causa dessa história, MFC:
- Tem um design bastante desajeitado. Tudo começou como um envoltório leve em torno da API do Windows, mas cresceu. Há um monte de pequenos 'recursos' que tiveram que ser inventados porque o compilador e a linguagem simplesmente não os suportavam. Não havia modelos, eles inventaram uma classe de string, eles inventaram classes de lista, eles projetaram sua própria identificação de tipo de tempo de execução, etc.
- Encapsula 20 anos de evolução do Office e do Windows, que inclui um monte de coisas que você provavelmente nunca usará: interfaces de documentos únicos e múltiplos, DDE, COM, COM +, DCOM, vinculação e incorporação de documentos (para que você possa incorporar um documento do Word em seu aplicativo se você quiser), controles ActiveX (evolução da incorporação de objetos para a web!), Armazenamento de documentos estruturados, serialização e controle de versão, automação (desde os primeiros anos do VBA) e, claro, MVC. As versões mais recentes têm suporte para encaixe de janela no estilo Visual Studio e a faixa de opções do Office. Basicamente, toda tecnologia de Redmond em 20 anos está lá em algum lugar. É simplesmente ENORME!
- Tem uma tonelada de pequenas pegadinhas, bugs, soluções alternativas, suposições, suporte para coisas que ainda estão lá e que você nunca usará e que causam problemas. Você precisa estar intimamente familiarizado com a implementação de muitas classes e como elas interagem para usá-la em um projeto de tamanho decente. Explorar o código-fonte do MFC durante a depuração é comum. Ainda acontece encontrar uma nota técnica de 15 anos em algum ponteiro sendo nulo, causando um travamento. Suposições sobre a inicialização de material de incorporação de documentos antigos podem afetar seu aplicativo de maneiras estranhas. Não existe abstração no MFC, você precisa trabalhar com suas peculiaridades e detalhes internos diariamente, não esconde nada. E não me fale sobre o assistente de classe.
ATL foi inventado com a evolução da linguagem C ++ e os modelos chegaram. ATL foi uma demonstração de como usar modelos para evitar os problemas de tempo de execução da biblioteca MFC:
- Mapas de mensagens: como são baseados em modelos, os tipos são verificados e, se você bagunçar a função vinculada, ela não será compilada. No MFC, os mapas de mensagens são baseados em macro e vinculados ao tempo de execução. Isso pode causar bugs estranhos, mensagem direcionada para a janela errada, um travamento se você tiver uma função ou macro definida incorretamente, ou simplesmente não funcionar porque algo não está conectado corretamente. Muito mais difícil de depurar e mais fácil de quebrar sem perceber.
- COM / automação: semelhante aos mapas de mensagem, o COM era originalmente vinculado ao tempo de execução usando macros, exigindo muitos erros de tratamento e causando problemas estranhos. ATL o tornou baseado em modelo, com limite de tempo de compilação e muito, muito mais fácil de lidar.
[Editar enfeite: na época em que o ATL foi criado, o roteiro técnico da Microsoft estava focado principalmente em 'Gerenciamento de documentos'. A Apple os estava matando no mercado de editoração eletrônica. A 'vinculação e incorporação de documentos' do Office foi um componente principal para aprimorar os recursos de 'Gerenciamento de documentos' do Office para competir neste espaço. COM foi uma tecnologia central inventada para integração de aplicativos, e as APIs de incorporação de documentos foram baseadas em COM. O MFC era difícil de usar neste caso de uso. ATL foi uma boa solução para tornar esta tecnologia específica mais fácil para terceiros implementarem COM e utilizarem recursos de incorporação de documentos.]
Essas pequenas melhorias tornam o ATL extremamente mais fácil de lidar em um aplicativo simples que não precisa de todos os recursos do Office like do MFC. Algo com uma interface de usuário simples e alguma automação de escritório incluída. É pequeno, é rápido e tem limite de tempo de compilação economizando muito tempo e dor de cabeça. O MFC tem uma enorme biblioteca de classes que podem ser desajeitadas e difíceis de trabalhar.
Infelizmente, o ATL estagnou. Ele tinha wrappers para a API do Windows e suporte COM, mas nunca foi além disso. Quando a Web decolou, todas essas coisas foram meio que esquecidas como notícias antigas.
[Editar enfeite: a Microsoft percebeu que essa 'Coisa da Internet' seria grande. Seu roteiro técnico mudou drasticamente para se concentrar no Internet Explorer, Windows Server, IIS, ASP, SQL Server, COM / DCOM no Distributed Transaction Server. Portanto, a vinculação e incorporação de documentos não era mais uma prioridade alta.]
A grande pegada do MFC tornou impossível para eles fazerem o dump, então ele ainda evolui lentamente. Os modelos foram incorporados de volta à biblioteca, bem como outros aprimoramentos de linguagem e API. (Eu não tinha ouvido falar do WTL até ver esta pergunta. :)
No final das contas, qual deles usar é simplesmente uma questão de preferência. A maioria dos recursos de que você precisa está na API do sistema operacional base, que pode ser chamada diretamente de qualquer uma das bibliotecas, se não houver um wrapper adequado na biblioteca.
Apenas meus 2 centavos com base no uso do MFC por muitos anos, e agora o uso diariamente. Eu me interessei pelo ATL quando ele foi lançado pela primeira vez em alguns projetos por alguns anos. Era uma lufada de ar fresco naquela época, mas nunca foi realmente a lugar nenhum. E então a Web apareceu e eu esqueci completamente dela.
Edit: Esta resposta tem uma longevidade surpreendente. Como ele continua aparecendo em minha página de estouro de pilha, pensei em adicionar um pouco de enfeite à resposta original que achei que estava faltando.