存在的必是合理的，都值得我們學習。學什么不重要，重要的是有一技之長。
如果你認為MFC垃圾請不要繼續看。
如果你認為文檔視圖結構丑陋請不要繼續看。
如果你認為ATL過時了請不要繼續看。

庖丁解牛的藝術
庖丁為文惠君解牛，分解牛體時手接觸的地方，肩靠著的地方，腳踩踏的地方，膝抵住的地方，都發出砉砉的聲響，快速進刀時刷刷的聲音，無不像美妙的音樂旋律，符合桑林舞曲的節奏，又合于經首樂曲的樂律。庖丁的解釋是：我所喜好的是摸索事物的規律，比起一般的技術、技巧又進了一層。我開始分解牛體的時候，所看見的沒有不是一頭整牛的。幾年之后，就不曾再看到整體的牛了。現在，我只用心神去接觸而不必用眼睛去觀察，眼睛的官能似乎停了下來而精神世界還在不停地運行。最喜歡這句：以無厚入有間，恢恢乎其于游刃必有余地矣。

我的MFC經歷
我的大學專業是軟件工程，作為一個C++開發人員學習MFC是必然的。記得上大二的時候，有些課程和大三師哥們一起上，總能看到牛師哥們手里捧一本《深入淺出MFC》，羨慕不已。當時數據結構實習，人家都基于Windows做，而自己只能在Console下做，十分尷尬，覺得自己很落后，現在想來有點可笑。
這里要說的是MFC是對WIN32 API的封裝，為什么不從WIN32 API開始學呢？很多人是這樣做，也見過一些人在這上面氣餒而放棄C++轉向Java。我是從MFC開始的，當我對MFC比較熟悉的時候，我心里就明白MFC是如何對WIN32 API封裝的，進入MFC源碼，里面全部調用的API，自然明白了API的功能及用法。學習編程就得由簡到難，對MFC深入后，WIN32 API自然淺出。
我是大三開始接觸MFC的，當時感覺是MFC是一個龐然大物，拿一些快速進階之類的書籍東拼西湊學一點技巧，三個月后也沒有入門。VC6向導生成的一個多文檔程序代碼比起自己寫過的數據結構代碼是一個天文數字，不知道如何下手。看著旁邊宿舍非計算機專業的學生用VB就能寫一個時鐘，羨慕啊，自卑啊，氣憤之下開始VB的學習。然而倔強的心里告訴自己怎么可以這樣認輸呢？在一個星期過去后，我重新開始了MFC的學習。MFC向導可以生成三種應用工程：對話框、單文檔、多文檔。默認的是微軟最為驕傲的多文檔，但是這個確實害人不淺。其他編程開發環境沒有文檔視圖的概念，都是窗體、Form，這個結構要簡單不少，可以快速入門，找到快感，不至于氣餒。我當時就是從對話框開始學習的，向導生成的類比較簡單，一個App，一個Dlg。我開始在對話框上學習各種控件，Button、Edit、ListCtrl等，終于算是Windows編程了。大概用了半年時間學習對話框，在對話框編程有一定了解的時候可以用它來做一些數據庫、Socket編程，經典例子就是管理系統和聊天工具。對MFC有一些了解后開始學習文檔視圖模型，開始從單文檔入手，然后進入到多文檔。文檔視圖主要是開發企業應用，要考慮菜單、工具欄、停靠條、文檔數據到視圖更新以及鼠標鍵盤交互等，考慮很多消息事件處理，掌握起來確實要花不少功夫。
大四我進入公司實習，當時以為對MFC很了解，覺得自己很了不起。當遇到稍微深一點的問題，斷點進入MFC源碼的時候便手無所措，原來自己只是對MFC的輪廓有一點了解，并不解其內部規律。當時受了打擊，這使我靜下心來深入研究MFC，再一次看《深入淺出MFC》、操練各種類型應用程序、分類學習WIN32 API、看MFC源碼（不敢說很仔細看，至少比較細的瀏覽一邊），當我可以進入到MFC源碼調試的時候，我很高興，因為我進步了。當我接觸到BCG庫和XTREME庫的時候，我都要進入它的源代碼看，發現里面很多代碼和MFC源碼一樣，我想寫庫的那些人對MFC應該算是很了解。而后我又花了半年時間學習COM，用ATL做項目。
現在每當我拿到一款軟件的時候，我總要用Spy++去看看它的構造，想一下如果是自己能否做出這樣的軟件。軟件設計不是靠蠻力，而是靠技巧，懂得借力省力。軟件好比一頭牛，模塊之間的松耦合就像牛骨頭依靠筋皮肉連接一樣，當你了解其構造后，你看到的是每一個模塊具有什么功能，可以拿來做什么，一個軟件可以有那些模塊拼湊，彼此間如何通信。恢恢乎其于游刃必有余地矣!

文檔視圖的剝離（App平臺 文檔視圖插件）
軟件開發講究分工合作，因為要考慮開發周期及市場。一個企業軟件有幾種業務：三維瀏覽、二維數據編輯、網絡控制。作為企業軟件應該有統一的框架，像.NET集成VB.NET、C#、VC.NET一樣，這樣就需要把框架和文檔視圖分離，在一個框架上，不同開發部門開發不同應用最后集成到統一應用框架。
首先來看看用向導生成的一個多文檔程序，主框架和文檔視圖子框架的聯系其實只有很少代碼：

CMultiDocTemplate * ?pDocTemplate;
pDocTemplate? = ? new ?CMultiDocTemplate(
?IDR_TESTTYPE,
?RUNTIME_CLASS(CTestDoc),
?RUNTIME_CLASS(CChildFrame),? // ?custom?MDI?child?frame
?RUNTIME_CLASS(CTestView));
AddDocTemplate(pDocTemplate);

我們把這一段代碼刪除，并且刪除關聯的CTestDoc、CChildFrame、CTestView類。這時候我們得到一個空框架的應用程序。
很明顯框架需要的只是文檔視圖子框架運行時的類信息，我們的文檔視圖插件需要遵守這樣一個規則，于是我們定義一個插件接口：

interface ?IDocView?:?IUnknown
{
?[id( 1 ),?helpstring( " method?GetDocCls " ),?hidden]?HRESULT?GetDocCls([ out ,?retval] long * ?pDocCls);
?[id( 2 ),?helpstring( " method?GetViewCls " ),?hidden]?HRESULT?GetViewCls([ out ,?retval] long * ?pViewCls);
?[id( 3 ),?helpstring( " method?GetChldFrm " ),?hidden]?HRESULT?GetChldFrm([ out ,?retval] long * ?pChldFrm);

為了插件查找以及管理，需要一個類別，所有支持的插件都屬于這個類別：

BEGIN_CATEGORY_MAP(CManager)
?IMPLEMENTED_CATEGORY(CATID_DocViewCategory)
END_CATEGORY_MAP()

下面就可以實現文檔視圖插件了，生產一個ATL項目，添加文檔視圖子框架類，添加一個組件Manager，實現插件接口：

STDMETHODIMP?CManager::GetDocCls( long * ?pDocCls)
{
? * pDocCls? = ?( long )RUNTIME_CLASS(CMyDocument);
? return ?S_OK;
}

STDMETHODIMP?CManager::GetViewCls( long * ?pViewCls)
{
? * pViewCls? = ?( long )RUNTIME_CLASS(CMyFormView);
? return ?S_OK;
}

STDMETHODIMP?CManager::GetChldFrm( long * ?pChldFrm)
{
? * pChldFrm? = ?( long )RUNTIME_CLASS(CChildFrame);
? return ?S_OK;
}

這樣就主框架就可以遍歷組件類別下面所有文檔視圖插件，通過

pDocTemplate? = ? new ?CMultiDocTemplate(
??IDR_MAINFRAME,
??(CRuntimeClass * )nDocCls,
??(CRuntimeClass * )nChldFrm,
??(CRuntimeClass * )nViewCls);
AddDocTemplate(pDocTemplate);

加入到主框架。
這里有一個問題：一個應用可能有20種文檔視圖，是不是應用一起來就查找所有支持插件并加載呢？從內存消耗和人的習慣思考來看都不應該是這樣的。可能一個用戶打開應用只編輯一類文檔，這時候其他19種文檔就不需要加載。這就需要一點技巧來處理這類問題。
簡單做法可以這樣處理：應用框架加載的時候便利所有插件，這時候不加載。當新建文件的時候查找新建的插件是否已經加載，如果沒有加載則先加載。打開文件的時候做類似操作。有如下三個函數完成操作：

// ?遍歷所有文檔插件，不加載
void ?EnumAllDocViews();
// ?根據插件CLSID加載文檔視圖插件
CMultiDocTemplate * ?AddDocViewByCLSID(CLSID?clsid);
// ?根據CLSID查找插件是否加載
DocMgrData?FindDocByCLSID(CLSID?clsid);

插件管理之插件類別：

打開界面：

打開文檔：

代碼下載。里面有說明文件。