微軟基礎類(Microsoft Foundation Classes),實際上是微軟提供的,用于在C++環境下編寫應用程序的一個框架和引擎,VC++是WinOS下開發人員使用的專業C++ SDK(SDK,Standard SoftWare Develop Kit,專業軟件開發平臺),MFC就是掛在它之上的一個輸助軟件開發包,MFC作為與VC++血肉相連的部分(注意C++和VC++的區別:C++是一種程序設計語言,是一種大家都承認的軟件編制的通用規范,而VC++只是一個編譯器,或者說是一種編譯器+源程序編輯器的IDE,WS,PlatForm,這跟Pascal和Dephi的關系一個道理,Pascal是Dephi的語言基礎,Dephi使用Pascal規范來進行Win下應用程序的開發和編譯,卻不同于Basic語言和VB的關系,Basic語言在VB開發出來被應用的年代已經成了Basic語言的新規范,VB新加的Basic語言要素,如面對對象程序設計的要素,是一種性質上的飛躍,使VB既是一個IDE,又成長成一個新的程序設計語言),MFC同BC++集成的VCL一樣是一個非外掛式的軟件包,類庫,只不過MFC類是微軟為VC++專配的..
MFC是Win API與C++的結合,API,即微軟提供的WinOS下應用程序的編程語言接口,是一種軟件編程的規范,但不是一種程序開發語言本身,可以允許用戶使用各種各樣的第三方(如我是一方,微軟是一方,Borland就是第三方)的編程語言來進行對Win OS下應用程序的開發,使這些被開發出來的應用程序能在WinOS下運行,比如VB,VC++,Java,Dehpi編程語言函數本質上全部源于API,因此用它們開發出來的應用程序都能工作在WinOS的消息機制和繪圖里,遵守WinOS作為一個操作系統的內部實現,這其實也是一種必要,微軟如果不提供API,這個世上對Win編程的工作就不會存在,微軟的產品就會迅速從時尚變成垃圾,上面說到MFC是微軟對API函數的專用C++封裝,這種結合一方面讓用戶使用微軟的專業C++ SDK來進行Win下應用程序的開發變得容易,因為MFC是對API的封裝,微軟做了大量的工作,隱藏了好多內節程序開發人員在Win下用C++ & MFC編制軟件時的大量內節,如應用程序實現消息的處理,設備環境繪圖,這種結合是以方便為目的的,必定要付出一定代價(這是微軟的一向作風),因此就造成了MFC對類封裝中的一定程度的的冗余和迂回,但這是可以接受的..
最后要明白MFC不只是一個功能單純的界面開發系統,它提供的類絕大部分用來進行界面開發,關聯一個窗口的動作,但它提供的類中有好多類不與一個窗口關聯,即類的作用不是一個界面類,不實現對一個窗口對象的控制(如創建,銷毀),而是一些在WinOS(用MFC編寫的程序絕大部分都在WinOS中運行)中實現內部處理的類,如數據庫的管理類等,學習中最應花費時間的是消息和設備環境,對C++和MFC的學習中最難的部分是指針,C++面向對像程序設計的其它部分,如數據類型,流程控制都不難,建議學習數據結構C++版..

二、什么是COM

----COM的發展及其局限性

        所謂COM（Componet Object Model，組件對象模型），是一種說明如何建立可動態互變組件的規范，此規范提供了為保證能夠互操作，客戶和組件應遵循的一些二進制和網絡標準。通過這種標準將可以在任意兩個組件之間進行通信而不用考慮其所處的操作環境是否相同、使用的開發語言是否一致以及是否運行于同一臺計算機。
COM的優點？
        首先：用戶一般希望能夠定制所用的應用程序，而組件技術從本質上講就是可被定制的，因而用戶可以用更能滿足他們需要的某個組件來替換原來的那個。其次，由于組件是相對應用程序獨立的部件，我們可以在不同的程序中使用同一個組件而不會產生任何問題，軟件的可重用性將大大的得到增強。第三，隨著網絡帶寬及其重要性的提高，分布式網絡應用程序毫無疑問的成為軟件市場上越來越重要的買點。組件價構可以使得開發這類應用程序的過程得以簡化。

什么是COM+？

         M+并不是COM的簡單升級，COM+的底層結構仍然以COM為基礎，它幾乎包容了COM的所有內容，COM+綜合了COM、DCOM和MTS這些技術要素，它把COM組件軟件提升到應用層而不再是底層的軟件結構，它通過操作系統的各種支持，使組件對象模型建立在應用層上，把所有組件的底層細節留給操作系統，因此，COM+與操作系統的結合更加緊密。
      COM+不再局限于COM的組件技術，它更加注重于分布式網絡應用的設計和實現。COM+繼承了COM幾乎全部的優勢，同時又避免了COM實現方面的一些不足，把COM、DCOM和MTS的編程模型結合起來，繼承了它們的絕大多數特性，在原有的特性上增加了新的功能。

 COM+的新的優點?

      以下列出COM+的幾個主要特性：

          COM+不僅繼承了COM所有的優點，而且還增加了一些服務，比如隊列服務、負載平衡、內存數據庫、事件服務等。

　　 隊列服務對于分布式應用非常有意義，特別是在現在網絡速度很慢的情況下，這種機制可以保證應用系統能夠可靠地運行。在應用系統包含大量節點但服務器又繁忙的情況下，客戶應用程序可以把它們的請求放到隊列中，當服務器負載比較輕的時候再處理這些請求；

　　 又如COM+提供了負載平衡服務，它可以實現動態負載平衡，而且COM+應用程序的負載平衡特性并不需要編寫代碼來支持，客戶程序和組件程序都可以按通常的方式實現。獲得負載平衡特性并不是用程序設計的方式來實現的，而是通過配置實現分布式應用程序的負載平衡，如上所講的隊列服務，其實也反映了一種負載平衡。

     (1) 真正的異步通訊。COM+底層提供了隊列組件服務，這使客戶和組件有可能在不同的時間點上協同工作，COM+應用無須增加代碼就可以獲得這樣的特性。

     (2) 事件服務。新的事件機制使事件源和事件接收方實現事件功能更加靈活，利用系統服務簡化了事件模型，避免了COM可連接對象機制的瑣碎細節。

     (3) 可伸縮性。COM+的可伸縮性來源于多個方面，動態負載平衡以及內存數據庫、對象池等系統服務都為COM+的可伸縮性提供了技術基礎，COM+的可伸縮性原理上與多層結構的可伸縮特性一致。

     (4) 可管理和可配置性。管理和配置是應用系統開發完成后的行為，在軟件維護成本不斷增加的今天，COM+應用將有助于軟件廠商和用戶減少這方面的投入。

     (5) 易于開發。COM+應用開發的復雜性和難易程度將決定COM+的成功與否，雖然COM+開發模型比以前的COM組件開發更為簡化，但真正提高開發效率仍需要借助于一些優秀的開發工具。

      COM+標志著Microsoft的組件技術達到了一個新的高度，它不再局限于一臺機器上的桌面系統，它把目標指向了更為廣闊的企業內部網，甚至Internet國際互連網絡。COM+與多層結構模型以及Windows操作系統為企業應用或Web應用提供了一套完整的解決方案。
 
 
三、什么是ATL

----自從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是ActiveXTemplateLibrary的縮寫，它是一套C++模板庫。使用ATL能夠快速地開發出高效、簡潔的代碼，同時對COM組件的開發提供最大限度的代碼自動生成以及可視化支持。為了方便使用，從MicrosoftVisualC++5.0版本開始，Microsoft把ATL集成到VisualC++開發環境中。1998年9月推出的VisualStudio6.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技術的支持在網絡應用的環境下也顯得很不靈活。

后補:

什么是ORM?

對象關系映射（Object Relational Mapping，簡稱ORM）是一種為了解決面向對象與關系數據庫存在的互不匹配的現象的技術。簡單的說，ORM是通過使用描述對象和數據庫之間映射的元數據，將java程序中的對象自動持久化到關系數據庫中。本質上就是將數據從一種形式轉換到另外一種形式。這也同時暗示者額外的執行開銷；然而，如果ORM作為一種中間件實現，則會有很多機會做優化，而這些在手寫的持久層并不存在。更重要的是用于控制轉換的元數據需要提供和管理；但是同樣，這些花費要比維護手寫的方案要少；而且就算是遵守ODMG規范的對象數據庫依然需要類級別的元數據。

對象-關系映射（Object/Relation Mapping，簡稱ORM），是隨著面向對象的軟件開發方法發展而產生的。面向對象的開發方法是當今企業級應用開發環境中的主流開發方法，關系數據庫是企業級應用環境中永久存放數據的主流數據存儲系統。對象和關系數據是業務實體的兩種表現形式，業務實體在內存中表現為對象，在數據庫中表現為關系數據。內存中的對象之間存在關聯和繼承關系，而在數據庫中，關系數據無法直接表達多對多關聯和繼承關系。因此，對象-關系映射(ORM)系統一般以中間件的形式存在，主要實現程序對象到關系數據庫數據的映射。

面向對象是從軟件工程基本原則(如耦合、聚合、封裝)的基礎上發展起來的，而關系數據庫則是從數學理論發展而來的，兩套理論存在顯著的區別。為了解決這個不匹配的現象,對象關系映射技術應運而生。

讓我們從O/R開始。字母O起源于"對象"(Object),而R則來自于"關系"(Relational)。幾乎所有的程序里面，都存在對象和關系數據庫。在業務邏輯層和用戶界面層中，我們是面向對象的。當對象信息發生變化的時候，我們需要把對象的信息保存在關系數據庫中。

當你開發一個應用程序的時候(不使用O/R Mapping),你可能會寫不少數據訪問層的代碼，用來從數據庫保存，刪除，讀取對象信息，等等。你在DAL中寫了很多的方法來讀取對象數據，改變狀態對象等等任務。而這些代碼寫起來總是重復的

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/yanghao58686763/archive/2008/03/17/2192578.aspx