算起來，我用Visual C++也有將近5年的歷史了。在這期間，我也曾涉獵過Visual Basic和Delphi，但都是淺嘗而止；Visual C++始終是我的主業。可是努力的成果如何呢？我用Delphi作出了十多個有規模的軟件，用VB－－雖然我用在VB上的時間只有短短的兩三個月－－也有兩個像樣的項目；然而，在我付出了最大熱情和最多努力的Visual C++上面，卻只作出了三個自己看得上眼的軟件。
固然，在用Visual C++的時候，MFC幫了我不少的忙。但是，在寫下這個題目之時，我就已經打定主意：在這篇文章中，只對MFC提出批評，不說MFC的好話。Visual C++的擁護者且慢發難，聽我道出其中原因。我注意到，象候捷先生這樣對MFC極其熱愛的著者，在其大著《深入淺出MFC》中對MFC的評價也是盡量的做到客觀和公允；而大師Charles Petzold和Jeff Prosise，在他們的作品中也只是給予MFC以謹慎的贊美。Charles Petzold還很客氣的指出了MFC的局限。然而另外一些編程書籍的作者，特別是某些國內的作者，似乎毫不吝惜把最華麗的語言和最夸張的贊美賦予 MFC，從書架上任意翻開一本介紹Visual C++的書籍，看看它的前言和序章，往往充斥著讓人目眩的溢美之辭。多少初學者被這些充滿暗示和誘導的辭令吸引，以為MFC是完全可視化的，象VB一樣容易掌握的東西，當他們深入以后，會不會有上當的感覺呢？我痛恨一切不負責任的夸大和炫耀，特別是只為了增加書籍銷量而不惜昧著良心說話的作者，而我的感覺是現在這樣的作者和書籍似乎已經泛濫了。本著矯枉必須過正的指導思想，我的目的很明確，就是要批評MFC。對Visual C++和MFC非常熟悉的讀者，我無慮您對本文提出批評和指責，因為您對MFC已經有了自己的觀點，不會為我所誤導；對Visual C++的入門者，我希望您在聽夠了對Visual C++和MFC的贊美之后，來聽聽另一種聲音，即使它并不完全正確（甚或是充滿謬誤），至少能讓您帶著自己的思想來看待您將要學習的東西。
對MFC的批判之一：不支持屬性，MFC憑什么同其他語言抗衡？
竊以為在編程語言中引入“Property”的概念是在面向對象的編程思想后最為重大的革新之一。其實，目前市場上絕大部分編程語言，包括VB, Delphi,C++Builder和PowerBuilder等等都支持Property。程序員只要簡單的修改對象的屬性，就能夠完成相當部分的工作，不僅是減少了無謂的勞動，更重要的是減少了出錯的機會，并且使得生成更復雜的界面和完成更復雜的工作成為相對容易的工作。我想絕大部分人會同意，如果去掉了Property這個東西，那么象VB和Delphi這樣好的RAD，包括Microsoft一直倡導的ActiveX，都會失去了絕大部分的魅力。這個道理，Microsoft應該是在推出Visual Basic 1.0的時候就認識到了。可是自從Visual C++誕生到現在，它似乎絲毫沒有使用Property的意思，雖然Visual C++這個名字在很大程序上沾了它的長兄Visual Basic的光，不過它并沒有從VB那里學到如何讓編程更簡單和更輕松的秘訣。
有人可能會說，data member of class不是property嗎？不是的，如果你用過C++Builder的話你一定能明白這種分別。MFC從來就不支持Property，而且今后看來也不會了，這意味著用MFC，你還是得干苦力活。(ActiveX？不錯，ActiveX支持Property，而且MFC支持ActiveX開發，不過這并不是三段論發揮作用的地方。)
對MFC的批判之二：單調的處理方式使本來應該簡單的工作變得復雜
應該沒有人反對這樣的觀點：用Visual C++開發界面，特別是不符合Microsoft所謂“標準”的程序，比VB，Delphi或是C++Builder都要慢得多。（附帶說一句，我不知道 Microsoft制定Windows Logo標準，并且要求程序員遵守的依據是什么；我自己的程序99％以上都不符合這個標準。）可這是為什么呢？是C++語言在這方面的天生不足？肯定不是。
在我看來，罪魁禍首是MFC中的CDocTemplate，這個類規定了一種非常死板和機械的機制，即一個Document，一個View和一個FrameWnd綁定在一起。遺憾的是，實際情況往往復雜的多。對界面稍微稍微要求高一點的程序大多要求一個Document有多個View，甚至在某些程序中，希望在同一個View中顯示多個Document的內容：比如，將兩個公司的業績放在一起作比較。對View和FrameWnd的關系也有類似的情況。然而，DocTemplate的機制使得這樣并不高的要求變的相當困難。想實現你的要求嗎？可以。你要添加新的View類。你要從默認的 IDR_MAINFRAME復制資源到新的類中。你要用AddDocTemplate添加自定義模板。你要用
GetFirstDocTemplatePosition和GetNextDocTemplate檢索模板列表。你要用GetDocString察看每個模板是否符合你的要求。你要重載CFrameWnd::OnCreateClient以派生新的視圖。你要用CView::SetDlgCtrlID和 CFrameWnd::SetActiveView以及CFrameWnd::RecalcLayout來在各個視圖中切換。你要用未公開的 CDocManager管理文檔模板。你要...還要嗎？反正我是怕了。
對MFC的批判之三：固步自封，不思進取
MFC 可以作為固步自封的活教材。別忘了，MFC是和Borland OWL同一時代的產物（還有多少人記得OWL呢？）當然，這不是MFC的錯誤。不過，如果以個類庫的體系自從2.0版本以來就沒有絲毫改變，是不是意味著這個類庫已經臻于完美了呢？不，即使Microsoft也不敢這么狂妄。但事實是，MFC的體系從MFC2.0以來就沒有變動過。每個版本的更新，不過是增加了一些新類，某些類的接口稍作修改，僅此而已。不，不要把ATL作為MFC的改進；ATL從來就不依賴于MFC。
誰都知道在這幾年中C++語言有了多么大的改進。包括RTTI，Dynamic Creation，Exception，Standard Template Library等等都成為新的C++標準的一部分。不過，Microsoft好像并不喜歡這些新東西，它的做法是另起爐灶；于是在同以套Visual C++中就出現了兩套互不兼容的實現。平心而論，在新的C++標準出臺前，Microsoft自己實現這些機制實在是一個相當了不起的創舉；但是歷史總是在發展的，MFC為什么不從善如流，盡量利用語言中已經實現的功能，而非要固執的用自己的一套老辦法？事實上，MFC幾乎沒有用到新的C++方案中任何有益的元素－－盡管這些方案已經對MFC庫中很多問題提出了相當完美而且精練的解決方法。
對MFC的批判之四：天然的傾向性
不知道您對AppWizard生成的默認項目有什么感覺。反正我的感覺是：這種工程就是用來開發象Word，Excel這樣的程序的。好像MFC天然的就傾向于這樣一種程序。但事實上，這種程序少之又少。
在Microsoft 看來，好像每個程序都應該有一個File菜單，而且這個菜單下面一定應該有New,Open,Save,Exit這些選項。在我的實際經驗來說，我只搞過一個程序符合這樣的要求。有多少人真的要搞一個自己的字處理程序或是電子表格呢？對于很多常見的、基于數據庫的程序，你需要New，Open和Save 嗎？如果是基于網絡的程序呢？特別是在多媒體程序和游戲程序中，MFC生成的框架與其說是幫助，不如說是累贅。
這倒是符合Microsoft的一貫風格：你要的只是特定的功能，它卻一并塞給你一大串不相干的東西，并且在很多時候，這些不相干的東西反而成為麻煩制造者。于是，我不得不在新生成一個項目后，不辭勞苦的去掉AppWizard“慷慨”的贈送品，包括大量無用的菜單和工具條按鈕，然后才能開始實際的工作。說實在的，AppWizard在為我減少工作量的同時，也增加了我不少勞動量。
MFC定義了一個Document-View框架，并且把Document定義的相當寬泛，幾乎可以代表任何數據。但是在實現上，Document是相當狹窄的；比如Document定義的Serialize固定的與一個CArchive對象聯系在一起，而CArchive又固定的與一個CFile聯系在一起，這樣實際上就限定Document處理的對象只能是磁盤文件。況且，在一個 Serialize中處理所有數據的序列化也是一種相當機械而死板的機制：它只能處理小量而且是一次處理完畢的數據，而實際上，程序往往要處理大塊的數據，并且不可能一次完成。在這種情況下，CDocument的處理機制反而是個障礙。此外，在很多類型的程序中，CDocument扮演的是一個很尷尬的角色：比如在絕大部分數據庫程序中，CDocument完全是個雞肋，實際的數據處理只能靠CRecordset來完成；再比如說，在最典型的Doc- View程序－－就是記事本程序－－中，CDocument根本是個無能的東西，因為它存取數據反而要求助于CEditView:: SerializeRaw。
Doc-View框架有可能突破這些限制嗎？完全可能。不過，你要有心理準備，如果你要這么作，你就必須求助于一大堆的未公開函數和類型，這些東西完全沒有文檔，依賴于你對MFC“底下的東西”究竟有多么熟悉，以及你是否愿意鉆研MFC的源代碼－－在絕大多數情況下這不是一件愉快的工作。如果你使用這些未公開的東西出了問題，或者你不知道如何使用，對不起，Microsoft不會給你任何支持－－誰教你不按照 Microsoft的邏輯工作來著！
對MFC的批判之五：什么是封裝？
好像這不成為一個問題。但是對MFC而言，封裝的定義是不成立的。這句話的意思是說，如果你不想生產玩具的話，如果你需要調試程序的話，如果你的代碼需要有比 AppWizard更多的東西，那么，MFC對你來說就不是封裝的。如果你的程序運行出了錯，對不起，問題不在你的代碼里面，而在MFC庫的某個文件中， Visual C++會為你打開這個文件，至于“為什么會出錯？”“這個函數究竟是用來干什么的？”MFC不會給你答案，你自求多福吧。如果你除了MSDN中的公開文檔以外，對MFC的源代碼從不關心，那么恭喜你，你是個快樂的程序員，但是你永遠不能生產出真正有用的程序。
候捷先生在其著作《深入淺出MFC》中也曾提到：或許有人會產生疑問，追尋“黑盒子底下的東西”，豈不有違面向對象編程的初衷？但是沒有辦法，不去熟悉MFC的源代碼，永遠只能生產玩具。候先生說的很委婉，盡量不批評MFC。但是，我可以這樣說：使用VB,Delphi,C++Builder，Java這些語言的程序員幾乎從來不去關心類庫的源代碼，可是這些語言并不是用來生產玩具的！