如果您想訂閱本博客內容，每天自動發到您的郵箱中， 請點這里

摘要: 什么是ATL(與COM的關系，及MFC與COM的關系)自從1993年Microsoft首次公布了COM技術以后，Windows平臺上的開發模式發生了巨大的變化，以COM為基礎的一系列軟件組件化技術將Windows編程帶入了組件化時代。廣大的開發人員在為COM帶來的軟件組件化趨勢歡欣鼓舞的同時，對于COM開發技術的難度和煩瑣的細節也感到極其的不便。COM編程一度被視為一種高不可攀的技術，令人望而卻步

什么是ATL (與COM的關系，及MFC與COM的關系)
自從1993年Microsoft首次公布了COM技術以后，Windows平臺上的開發模式發生了巨大的變化，以COM為基礎的一系列軟件組件化技術將Windows編程帶入了組件化時代。廣大的開發人員在為COM帶來的軟件組件化趨勢歡欣鼓舞的同時，對于COM開發技術的難度和煩瑣的細節也感到極其的不便。COM編程一度被視為一種高不可攀的技術，令人望而卻步。開發人員希望能夠有一種方便快捷的COM開發工具，提高開發效率，更好地利用這項技術。
針對這種情況，Microsoft公司在推出COMSDK以后，為簡化COM編程，提高開發效率，采取了許多方案，特別是在MFC（MicrosoftFoundationClass）中加入了對COM和OLE的支持。但是隨著Internet的發展，分布式的組件技術要求COM組件能夠在網絡上傳輸，而又盡量節約寶貴的網絡帶寬資源。采用MFC開發的COM組件由于種種限制不能很好地滿足這種需求，因此Microsoft在1995年又推出了一種全新的COM開發工具ATL。
ATL是ActiveX Template Library的縮寫，它是一套C++模板庫。使用ATL能夠快速地開發出、簡潔的代碼（Effectiveand Slimcode），同時對COM組件的開發提供最大限度的代碼自動生成以及可視化支持。為了方便使用，從MicrosoftVisual C++ 5.0版本開始，Microsoft把ATL集成到VisualC++開發環境中。1998年9月推出的Visual Studio 6.0 集成了ATL3.0版本。目前，ATL已經成為Microsoft標準開發工具中的一個重要成員，日益受到C++開發人員的重視。
ATL究竟給開發人員帶來了什么樣的益處呢？這還要先從ATL產生以前的COM開發方式說起。
在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對象的特性。
另外，在MFC中還提供對Automation 和 ActiveXControl的支持，對于這兩個方面，VisualC++也提供了相應的AppWizard和ClassWizard支持，這種可視化的工具更加方便了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的支持不能很好的滿足開發者的要求。
隨著Internet技術的發展，Microsoft將ActiveX技術作為其網絡戰略的一個重要組成部分大力推廣，然而使用MFC開發的ActiveXControl，代碼冗余量大（所謂的“肥代碼 FatCode”），而且必須要依賴于MFC的運行時刻庫才能正確地運行。雖然MFC的運行時刻庫只有部分功能與COM有關，但是由于MFC的繼承實現的本質，ActiveXControl必須背負運行時刻庫這個沉重的包袱。如果采用靜態連接MFC運行時刻庫的方式，這將使ActiveXControl代碼過于龐大，在網絡上傳輸時將占據寶貴的網絡帶寬資源；如果采用動態連接MFC運行時刻庫的方式，這將要求瀏覽器一方必須具備MFC的運行時刻庫支持。總之MFC對COM技術的支持在網絡應用的環境下也顯得很不靈活。
解決上述COM開發方法中的問題正是ATL的基本目標。
首先ATL的基本目標就是使COM應用開發盡可能地自動化，這個基本目標就決定了ATL只面向COM開發提供支持。目標的明確使ATL對COM技術的支持達到淋漓盡致的地步。對COM開發的任何一個環節和過程，ATL都提供支持，并將與COM開發相關的眾多工具集成到一個統一的編程環境中。對于COM/ActiveX的各種應用，ATL也都提供了完善的Wizard支持。所有這些都極大地方便了開發者的使用，使開發者能夠把注意力集中在與應用本身相關的邏輯上。
其次，ATL因其采用了特定的基本實現技術，擺脫了大量冗余代碼，使用ATL開發出來的COM應用的代碼簡練，即所謂的“SlimCode”。ATL在實現上盡可能采用優化技術，甚至在其內部提供了所有C/C++開發的程序所必須具有的C啟動代碼的替代部分。同時ATL產生的代碼在運行時不需要依賴于類似MFC程序所需要的龐大的代碼模塊，包含在最終模塊中的功能是用戶認為最基本和最必須的。這些措施使采用ATL開發的COM組件(包括ActiveXControl)可以在網絡環境下實現應用的分布式組件結構。
第三，ATL的各個版本對Microsoft的基于COM的各種新的組件技術如MTS、ASP等都有很好的支持，ATL對新技術的反應速度大大快于MFC。ATL已經成為Microsoft支持COM應用開發的主要開發工具，因此COM技術方面的新進展在很短的時間內都會在ATL中得到反映。這使開發者使用ATL進行COM編程可以得到直接使用COMSDK編程同樣的靈活性和強大的功能。
本文的目的就是希望在有限的篇幅中能夠使讀者對ATL的使用和基本原理有一個初步的了解，為廣大的COM開發人員更好地使用ATL開發起到拋磚引玉的作用。

藍藍設計( www.0391cbd.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務