VC 中的ATL和 MFC有什么區別

ATL是ActiveXTemplateLibrary的縮寫，它是一套C++模板庫。使用ATL能夠快速地開發出高效、簡潔的代碼，同時對COM組件的開發提供最大限度的代碼自動生成以及可視化支持。為了方便使用，從MicrosoftVisualC++5.0版本開始，Microsoft把ATL集成到VisualC++開發環境中。1998年9月推出的VisualStudio6.0集成了ATL3.0版本。
在ATL產生以前，開發COM組件的方法主要有兩種：一是使用COMSDK直接開發COM組件，另一種方式是通過MFC提供的COM支持來實現。
直接使用COMSDK開發COM組件是最基本也是最靈活的方式。通過使用Microsoft提供的開發包，我們可以直接編寫COM程序。但是，這種開發方式的難度和工作量都很大，一方面，要求開發者對於COM的技術原理具有比較深入的了解（雖然對技術本身的深刻理解對使用任何一種工具都是非常有益的，但對於COM這樣一整套復雜的技術而言，在短時間內完全掌握是很難的）；另一方面，直接使用COMSDK要求開發人員自己去實現COM應用的每一個細節，完成大量的重復性工作。這樣做的結果是，不僅降低了工作效率，同時也使開發人員不得不把許多精力投入到與應用需求本身無關的技術細節中。雖然這種開發方式對於某些特殊的應用很有必要，但這種編程方式並不符合組件化程序設計方法所倡導的可重用性，因此，直接采用COMSDK不是一種理想的開發方式。
使用MFC提供的COM支持開發COM應用可以說在使用COMSDK基礎上提高了自動化程度，縮短了開發時間。MFC采用面向對象的方式將COM的基本功能封裝在若干MFC的C++類中，開發者通過繼承這些類得到COM支持功能。為了使派生類方便地獲得COM對象的各種特性，MFC中有許多預定義宏，這些宏的功能主要是實現COM接口的定義和對象的注冊等通常在COM對象中要用到的功能。開發者可以使用這些宏來定制COM對象的特性。
隨着Internet技術的發展，Microsoft將ActiveX技術作為其網絡戰略的一個重要組成部分大力推廣，然而使用MFC開發的ActiveXControl，代碼冗余量大，即所謂的“肥代碼”（FatCode），而且必須要依賴於MFC的運行時刻庫才能正確地運行。雖然MFC的運行時刻庫只有部分功能與COM有關，但是由於MFC的繼承實現的本質，ActiveXControl必須背負運行時刻庫這個沉重的包袱。如果采用靜態連接MFC運行時刻庫的方式，這將使ActiveXControl代碼過於龐大，在網絡上傳輸時將占據寶貴的網絡帶寬資源；如果采用動態連接MFC運行時刻庫的方式，這將要求瀏覽器一方必須具備MFC的運行時刻庫支持。總之，MFC對COM技術的支持在網絡應用的環境下也顯得很不靈活。
MFC對COM和OLE的支持確實比手工編寫COM程序有了很大的進步。但是MFC對COM的支持還不夠完善和徹底，例如對COM接口定義的IDL語言，MFC並沒有任何支持，此外對於近些年來COM和ActiveX技術的新發展MFC也沒有提供靈活的支持。這是由MFC設計的基本出發點決定的。MFC被設計成對Windows平台編程開發的面向對象的封裝，自然要涉及Windows編程的方方面面，COM作為Windows平台編程開發的一個部分也得到MFC的支持，但是MFC對COM的支持是以其全局目標為出發點的，因此對COM的支持必然要服從其全局目標。從這個方面而言，MFC對COM的支持不能很好地滿足開發者的要求。

對於程序員來說，還有一個區別就是ATL要求你懂得更多的COM知識，這樣你才能直接使用ATL來編寫COM組件或者控件，而MFC甚至不要求你知道COM是個什么東西就能寫出一個ActiveX控件來了。
此外，如果你編寫的控件有GUI（圖形用戶界面）的話，你最好使用MFC；如果根本不需要GUI，那最好使用ATL編寫，當然你也可以選擇MFC來編寫不可見的控件，但是開銷比ATL大，而執行效率卻小於ATL；但是有時候這種差別所帶來影響可以忽略掉的話，那么我建議你還是用MFC來寫，唯一的理由是它開發起來更簡單，易於調試。如果你是一個COM的門外漢，卻又想使用ATL來編寫控件，那么建議你先准備半年時間（保守估計）來學習COM的理論知識

簡單地說,ATL在網絡應用普及的今天,開發效果(簡潔\高效)要比MFC好.但我本人覺得MFC也不差!我一直在用MFC做事!