存在的必是合理的，都值得我們學習。學什么不重要，重要的是有一技之長。如果你認為MFC垃圾請不要繼續看。如果你認為文檔視圖結構丑陋請不要繼續看。如果你認為ATL過時了請不要繼續看。MFC應用與框架的聯系要想分離應用與框架，首先得明白它們之間的聯系。用向導生產一個多文檔程序觀察，可以發現只有一處關聯：
選擇一個插件框架后：
有必要這樣做嘛？？這里演示了一個應用根據選擇不同的插件進入不同語言的界面，當然不是為了解決多國語言版本問題而這樣做（多國語言版本可以通過資源文件來解決）。這樣做到底有沒有必要呢？？再來看下向導生產的程序界面：
這里可以清楚看到子框架、文檔、視圖是一個模塊體，主框架、菜單、工具欄、狀態條是一個模塊體、后面看不見的應用app又是一個模塊體。這使我想起小時候的積木，一堆不同形狀的木塊，可以自由的想象去搭建房子汽車。軟件應該是軟的，是像積木一樣可以自由搭架自由組合的。有些人一直抱怨MFC死板，我也曾經熱衷去的研究一些小巧的界面庫WTL、fox、fltk，但是回頭來看用的最多的、對自己最有幫助然而也最另自己頭痛的還是MFC。軟件需要美觀，于是乎出來了許多基于MFC的界面庫，其中BCG、XTREME算是有名氣的。試想一個項目的開發需要多少人，又有多少人對BCG之類的庫熟悉（即使它很好用）。我曾經遇到過一個問題：BCG的DockBar標題在上面，占用很大一部分視圖，給人一種擁擠的感覺，而XTREME的標題在左側，這樣視圖看上去大許多。但是引入兩套界面庫是不實際的，于是自己想用MFC做一個。結果是用MFC的DockBar居然加不上去，由于涉及到一些其他問題，所以無奈只能忍受那個霸道的DockBar。最讓人無法忍受的是一些別出心裁的人在MFC對話框上加上一個漂亮的XP按鈕，哭笑不得。我也沖動認為給我Wnd和DC就可以作出任何想要的界面效果，花上幾天時間去繪制一個控件，響應各種消息，做完后才發現離專業美觀相差甚遠，而且放入到應用中不協調，影響軟件的商品化形象。軟件開發已經進入工業化時代了，手工蠻干顯得笨拙，對MFC進行封裝的界面庫自從有了皮膚之后也顯得蒼白無力。到底如何才能簡化軟件開發，提高軟件應變能力？？回到軟件設計的鐵定律：高內聚低耦合。從面向對象到面向構件到現在流行的面向服務軟件設計理念，無不遵守這條原則，不同只是技術上的更新。對于大型軟件的界面開發，拋開美觀（可以通過皮膚滿足）不談，MFC是值得我們研究的。從開發者的熟悉程度和提供解決方案能力來講，MFC都是最佳選擇。有人會說MFC提供的控件少，不利于開發，請清楚軟件開發已經進入工業化時代了，這已經不再是問題（后續文章會陸續解決）。軟件要想軟下來，盡量適應變化，只有降低耦合度。我們必須把MFC向導生產的框架拿來進行解剖，斬斷耦合的牽絆。這里把軟件抽象看作App、MainFrame、DocView組成，從上面的剝離可以看到，App與MainFrame、MainFrame與DocView之間是松耦合的，每一個部分是內聚的。只要保證每個部分之間可以正常通信，這樣一個App就可以對應多個MainFrame，一個MainFrame可以對應多個DocView。企業只要有App、MainFrame、DocView三個向導完成三者之間的通信，就足以開發各種不同需求的軟件。讓思維漫步在App、MainFrame和DocView剝離開之后，我又運行了向導生產的程序。發現選擇菜單的時候，狀態欄有信息提示。以前從沒有考慮過這些再普通不過的功能是如何實現的，突然之間覺得很神奇。我打開msdn，查閱MainFrame的基類CFrameWnd，里面有個SetMessageText函數，是狀態欄顯示信息用的。嗯，選擇菜單的時候一定會調用它。于是進入CFrameWnd的實現文件WINFRM.CPP，搜索SetMessageText發現OnEnterIdle()、OnIdleUpdateCmdUI()調用了它，
原來空閑的時候一直會檢測當前菜單跟蹤狀態。靜下心來，讓思維去自由漫步，當孤獨的智者。代碼下載。里面有說明文件。