微軟基礎(chǔ)類(Microsoft Foundation Classes),實(shí)際上是微軟提供的,用于在C++環(huán)境下編寫應(yīng)用程序的一個(gè)框架和引擎,VC++是WinOS下開發(fā)人員使用的專業(yè)C++ SDK(SDK,Standard SoftWare Develop Kit,專業(yè)軟件開發(fā)平臺(tái)),MFC就是掛在它之上的一個(gè)輸助軟件開發(fā)包,MFC作為與VC++血肉相連的部分(注意C++和VC++的區(qū)別:C++是一種程序設(shè)計(jì)語言,是一種大家都承認(rèn)的軟件編制的通用規(guī)范,而VC++只是一個(gè)編譯器,或者說是一種編譯器+源程序編輯器的IDE,WS,PlatForm,這跟Pascal和Dephi的關(guān)系一個(gè)道理,Pascal是Dephi的語言基礎(chǔ),Dephi使用Pascal規(guī)范來進(jìn)行Win下應(yīng)用程序的開發(fā)和編譯,卻不同于Basic語言和VB的關(guān)系,Basic語言在VB開發(fā)出來被應(yīng)用的年代已經(jīng)成了Basic語言的新規(guī)范,VB新加的Basic語言要素,如面對(duì)對(duì)象程序設(shè)計(jì)的要素,是一種性質(zhì)上的飛躍,使VB既是一個(gè)IDE,又成長成一個(gè)新的程序設(shè)計(jì)語言),MFC同BC++集成的VCL一樣是一個(gè)非外掛式的軟件包,類庫,只不過MFC類是微軟為VC++專配的..
MFC是Win API與C++的結(jié)合,API,即微軟提供的WinOS下應(yīng)用程序的編程語言接口,是一種軟件編程的規(guī)范,但不是一種程序開發(fā)語言本身,可以允許用戶使用各種各樣的第三方(如我是一方,微軟是一方,Borland就是第三方)的編程語言來進(jìn)行對(duì)Win OS下應(yīng)用程序的開發(fā),使這些被開發(fā)出來的應(yīng)用程序能在WinOS下運(yùn)行,比如VB,VC++,Java,Dehpi編程語言函數(shù)本質(zhì)上全部源于API,因此用它們開發(fā)出來的應(yīng)用程序都能工作在WinOS的消息機(jī)制和繪圖里,遵守WinOS作為一個(gè)操作系統(tǒng)的內(nèi)部實(shí)現(xiàn),這其實(shí)也是一種必要,微軟如果不提供API,這個(gè)世上對(duì)Win編程的工作就不會(huì)存在,微軟的產(chǎn)品就會(huì)迅速從時(shí)尚變成垃圾,上面說到MFC是微軟對(duì)API函數(shù)的專用C++封裝,這種結(jié)合一方面讓用戶使用微軟的專業(yè)C++ SDK來進(jìn)行Win下應(yīng)用程序的開發(fā)變得容易,因?yàn)镸FC是對(duì)API的封裝,微軟做了大量的工作,隱藏了好多內(nèi)節(jié)程序開發(fā)人員在Win下用C++ & MFC編制軟件時(shí)的大量?jī)?nèi)節(jié),如應(yīng)用程序?qū)崿F(xiàn)消息的處理,設(shè)備環(huán)境繪圖,這種結(jié)合是以方便為目的的,必定要付出一定代價(jià)(這是微軟的一向作風(fēng)),因此就造成了MFC對(duì)類封裝中的一定程度的的冗余和迂回,但這是可以接受的..
最后要明白MFC不只是一個(gè)功能單純的界面開發(fā)系統(tǒng),它提供的類絕大部分用來進(jìn)行界面開發(fā),關(guān)聯(lián)一個(gè)窗口的動(dòng)作,但它提供的類中有好多類不與一個(gè)窗口關(guān)聯(lián),即類的作用不是一個(gè)界面類,不實(shí)現(xiàn)對(duì)一個(gè)窗口對(duì)象的控制(如創(chuàng)建,銷毀),而是一些在WinOS(用MFC編寫的程序絕大部分都在WinOS中運(yùn)行)中實(shí)現(xiàn)內(nèi)部處理的類,如數(shù)據(jù)庫的管理類等,學(xué)習(xí)中最應(yīng)花費(fèi)時(shí)間的是消息和設(shè)備環(huán)境,對(duì)C++和MFC的學(xué)習(xí)中最難的部分是指針,C++面向?qū)ο癯绦蛟O(shè)計(jì)的其它部分,如數(shù)據(jù)類型,流程控制都不難,建議學(xué)習(xí)數(shù)據(jù)結(jié)構(gòu)C++版..
二、什么是COM
----COM的發(fā)展及其局限性
所謂COM（Componet Object Model，組件對(duì)象模型），是一種說明如何建立可動(dòng)態(tài)互變組件的規(guī)范，此規(guī)范提供了為保證能夠互操作，客戶和組件應(yīng)遵循的一些二進(jìn)制和網(wǎng)絡(luò)標(biāo)準(zhǔn)。通過這種標(biāo)準(zhǔn)將可以在任意兩個(gè)組件之間進(jìn)行通信而不用考慮其所處的操作環(huán)境是否相同、使用的開發(fā)語言是否一致以及是否運(yùn)行于同一臺(tái)計(jì)算機(jī)。
COM的優(yōu)點(diǎn)？
首先：用戶一般希望能夠定制所用的應(yīng)用程序，而組件技術(shù)從本質(zhì)上講就是可被定制的，因而用戶可以用更能滿足他們需要的某個(gè)組件來替換原來的那個(gè)。其次，由于組件是相對(duì)應(yīng)用程序獨(dú)立的部件，我們可以在不同的程序中使用同一個(gè)組件而不會(huì)產(chǎn)生任何問題，軟件的可重用性將大大的得到增強(qiáng)。第三，隨著網(wǎng)絡(luò)帶寬及其重要性的提高，分布式網(wǎng)絡(luò)應(yīng)用程序毫無疑問的成為軟件市場(chǎng)上越來越重要的買點(diǎn)。組件價(jià)構(gòu)可以使得開發(fā)這類應(yīng)用程序的過程得以簡(jiǎn)化。
什么是COM+？
M+并不是COM的簡(jiǎn)單升級(jí)，COM+的底層結(jié)構(gòu)仍然以COM為基礎(chǔ)，它幾乎包容了COM的所有內(nèi)容，COM+綜合了COM、DCOM和MTS這些技術(shù)要素，它把COM組件軟件提升到應(yīng)用層而不再是底層的軟件結(jié)構(gòu)，它通過操作系統(tǒng)的各種支持，使組件對(duì)象模型建立在應(yīng)用層上，把所有組件的底層細(xì)節(jié)留給操作系統(tǒng)，因此，COM+與操作系統(tǒng)的結(jié)合更加緊密。
COM+不再局限于COM的組件技術(shù)，它更加注重于分布式網(wǎng)絡(luò)應(yīng)用的設(shè)計(jì)和實(shí)現(xiàn)。COM+繼承了COM幾乎全部的優(yōu)勢(shì)，同時(shí)又避免了COM實(shí)現(xiàn)方面的一些不足，把COM、DCOM和MTS的編程模型結(jié)合起來，繼承了它們的絕大多數(shù)特性，在原有的特性上增加了新的功能。
COM+的新的優(yōu)點(diǎn)?
以下列出COM+的幾個(gè)主要特性：
COM+不僅繼承了COM所有的優(yōu)點(diǎn)，而且還增加了一些服務(wù)，比如隊(duì)列服務(wù)、負(fù)載平衡、內(nèi)存數(shù)據(jù)庫、事件服務(wù)等。
隊(duì)列服務(wù)對(duì)于分布式應(yīng)用非常有意義，特別是在現(xiàn)在網(wǎng)絡(luò)速度很慢的情況下，這種機(jī)制可以保證應(yīng)用系統(tǒng)能夠可靠地運(yùn)行。在應(yīng)用系統(tǒng)包含大量節(jié)點(diǎn)但服務(wù)器又繁忙的情況下，客戶應(yīng)用程序可以把它們的請(qǐng)求放到隊(duì)列中，當(dāng)服務(wù)器負(fù)載比較輕的時(shí)候再處理這些請(qǐng)求；
又如COM+提供了負(fù)載平衡服務(wù)，它可以實(shí)現(xiàn)動(dòng)態(tài)負(fù)載平衡，而且COM+應(yīng)用程序的負(fù)載平衡特性并不需要編寫代碼來支持，客戶程序和組件程序都可以按通常的方式實(shí)現(xiàn)。獲得負(fù)載平衡特性并不是用程序設(shè)計(jì)的方式來實(shí)現(xiàn)的，而是通過配置實(shí)現(xiàn)分布式應(yīng)用程序的負(fù)載平衡，如上所講的隊(duì)列服務(wù)，其實(shí)也反映了一種負(fù)載平衡。
(1) 真正的異步通訊。COM+底層提供了隊(duì)列組件服務(wù)，這使客戶和組件有可能在不同的時(shí)間點(diǎn)上協(xié)同工作，COM+應(yīng)用無須增加代碼就可以獲得這樣的特性。
(2) 事件服務(wù)。新的事件機(jī)制使事件源和事件接收方實(shí)現(xiàn)事件功能更加靈活，利用系統(tǒng)服務(wù)簡(jiǎn)化了事件模型，避免了COM可連接對(duì)象機(jī)制的瑣碎細(xì)節(jié)。
(3) 可伸縮性。COM+的可伸縮性來源于多個(gè)方面，動(dòng)態(tài)負(fù)載平衡以及內(nèi)存數(shù)據(jù)庫、對(duì)象池等系統(tǒng)服務(wù)都為COM+的可伸縮性提供了技術(shù)基礎(chǔ)，COM+的可伸縮性原理上與多層結(jié)構(gòu)的可伸縮特性一致。
(4) 可管理和可配置性。管理和配置是應(yīng)用系統(tǒng)開發(fā)完成后的行為，在軟件維護(hù)成本不斷增加的今天，COM+應(yīng)用將有助于軟件廠商和用戶減少這方面的投入。
(5) 易于開發(fā)。COM+應(yīng)用開發(fā)的復(fù)雜性和難易程度將決定COM+的成功與否，雖然COM+開發(fā)模型比以前的COM組件開發(fā)更為簡(jiǎn)化，但真正提高開發(fā)效率仍需要借助于一些優(yōu)秀的開發(fā)工具。
COM+標(biāo)志著Microsoft的組件技術(shù)達(dá)到了一個(gè)新的高度，它不再局限于一臺(tái)機(jī)器上的桌面系統(tǒng)，它把目標(biāo)指向了更為廣闊的企業(yè)內(nèi)部網(wǎng)，甚至Internet國際互連網(wǎng)絡(luò)。COM+與多層結(jié)構(gòu)模型以及Windows操作系統(tǒng)為企業(yè)應(yīng)用或Web應(yīng)用提供了一套完整的解決方案。
三、什么是ATL
----自從1993年Microsoft首次公布了COM技術(shù)以后，Windows平臺(tái)上的開發(fā)模式發(fā)生了巨大的變化，以COM為基礎(chǔ)的一系列軟件組件化技術(shù)將Windows編程帶入了組件化時(shí)代。廣大開發(fā)人員在為COM帶來的軟件組件化趨勢(shì)歡欣鼓舞的同時(shí)，對(duì)于COM開發(fā)技術(shù)的難度和煩瑣的細(xì)節(jié)也感到極其的不便。COM編程一度被視為一種高不可攀的技術(shù)，令人望而卻步。開發(fā)人員希望能夠有一種方便快捷的COM開發(fā)工具，提高開發(fā)效率，更好地利用這項(xiàng)技術(shù)。
----針對(duì)這種情況，Microsoft公司在推出COMSDK以后，為簡(jiǎn)化COM編程，提高開發(fā)效率，采取了許多方案，特別是在MFC（MicrosoftFoundationClass）中加入了對(duì)COM和OLE的支持。但是隨著Internet的發(fā)展，分布式的組件技術(shù)要求COM組件能夠在網(wǎng)絡(luò)上傳輸，而又盡量節(jié)約寶貴的網(wǎng)絡(luò)帶寬資源。采用MFC開發(fā)的COM組件由于種種限制不能很好地滿足這種需求，因此Microsoft在1995年又推出了一種全新的COM開發(fā)工具——ATL。
----ATL是ActiveXTemplateLibrary的縮寫，它是一套C++模板庫。使用ATL能夠快速地開發(fā)出高效、簡(jiǎn)潔的代碼，同時(shí)對(duì)COM組件的開發(fā)提供最大限度的代碼自動(dòng)生成以及可視化支持。為了方便使用，從MicrosoftVisualC++5.0版本開始，Microsoft把ATL集成到VisualC++開發(fā)環(huán)境中。1998年9月推出的VisualStudio6.0集成了ATL3.0版本。目前，ATL已經(jīng)成為Microsoft標(biāo)準(zhǔn)開發(fā)工具中的一個(gè)重要成員，日益受到C++開發(fā)人員的重視。
----ATL究竟給開發(fā)人員帶來了什么樣的益處呢？這要先從ATL產(chǎn)生以前的COM開發(fā)方式說起。
----在ATL產(chǎn)生以前，開發(fā)COM組件的方法主要有兩種：一是使用COMSDK直接開發(fā)COM組件，另一種方式是通過MFC提供的COM支持來實(shí)現(xiàn)。
----直接使用COMSDK開發(fā)COM組件是最基本也是最靈活的方式。通過使用Microsoft提供的開發(fā)包，我們可以直接編寫COM程序。但是，這種開發(fā)方式的難度和工作量都很大，一方面，要求開發(fā)者對(duì)于COM的技術(shù)原理具有比較深入的了解（雖然對(duì)技術(shù)本身的深刻理解對(duì)使用任何一種工具都是非常有益的，但對(duì)于COM這樣一整套復(fù)雜的技術(shù)而言，在短時(shí)間內(nèi)完全掌握是很難的）；另一方面，直接使用COMSDK要求開發(fā)人員自己去實(shí)現(xiàn)COM應(yīng)用的每一個(gè)細(xì)節(jié)，完成大量的重復(fù)性工作。這樣做的結(jié)果是，不僅降低了工作效率，同時(shí)也使開發(fā)人員不得不把許多精力投入到與應(yīng)用需求本身無關(guān)的技術(shù)細(xì)節(jié)中。雖然這種開發(fā)方式對(duì)于某些特殊的應(yīng)用很有必要，但這種編程方式并不符合組件化程序設(shè)計(jì)方法所倡導(dǎo)的可重用性，因此，直接采用COMSDK不是一種理想的開發(fā)方式。
----使用MFC提供的COM支持開發(fā)COM應(yīng)用可以說在使用COMSDK基礎(chǔ)上提高了自動(dòng)化程度，縮短了開發(fā)時(shí)間。MFC采用面向?qū)ο蟮姆绞綄OM的基本功能封裝在若干MFC的C++類中，開發(fā)者通過繼承這些類得到COM支持功能。為了使派生類方便地獲得COM對(duì)象的各種特性，MFC中有許多預(yù)定義宏，這些宏的功能主要是實(shí)現(xiàn)COM接口的定義和對(duì)象的注冊(cè)等通常在COM對(duì)象中要用到的功能。開發(fā)者可以使用這些宏來定制COM對(duì)象的特性。
----另外，在MFC中還提供對(duì)Automation和ActiveXControl的支持，對(duì)于這兩個(gè)方面，VisualC++也提供了相應(yīng)的AppWizard和ClassWizard支持，這種可視化的工具更加方便了COM應(yīng)用的開發(fā)。
----MFC對(duì)COM和OLE的支持確實(shí)比手工編寫COM程序有了很大的進(jìn)步。但是MFC對(duì)COM的支持還不夠完善和徹底，例如對(duì)COM接口定義的IDL語言，MFC并沒有任何支持，此外對(duì)于近些年來COM和ActiveX技術(shù)的新發(fā)展MFC也沒有提供靈活的支持。這是由MFC設(shè)計(jì)的基本出發(fā)點(diǎn)決定的。MFC被設(shè)計(jì)成對(duì)Windows平臺(tái)編程開發(fā)的面向?qū)ο蟮姆庋b，自然要涉及Windows編程的方方面面，COM作為Windows平臺(tái)編程開發(fā)的一個(gè)部分也得到MFC的支持，但是MFC對(duì)COM的支持是以其全局目標(biāo)為出發(fā)點(diǎn)的，因此對(duì)COM的支持必然要服從其全局目標(biāo)。從這個(gè)方面而言，MFC對(duì)COM的支持不能很好地滿足開發(fā)者的要求。
----隨著Internet技術(shù)的發(fā)展，Microsoft將ActiveX技術(shù)作為其網(wǎng)絡(luò)戰(zhàn)略的一個(gè)重要組成部分大力推廣，然而使用MFC開發(fā)的ActiveXControl，代碼冗余量大，即所謂的“肥代碼”（FatCode），而且必須要依賴于MFC的運(yùn)行時(shí)刻庫才能正確地運(yùn)行。雖然MFC的運(yùn)行時(shí)刻庫只有部分功能與COM有關(guān)，但是由于MFC的繼承實(shí)現(xiàn)的本質(zhì)，ActiveXControl必須背負(fù)運(yùn)行時(shí)刻庫這個(gè)沉重的包袱。如果采用靜態(tài)連接MFC運(yùn)行時(shí)刻庫的方式，這將使ActiveXControl代碼過于龐大，在網(wǎng)絡(luò)上傳輸時(shí)將占據(jù)寶貴的網(wǎng)絡(luò)帶寬資源；如果采用動(dòng)態(tài)連接MFC運(yùn)行時(shí)刻庫的方式，這將要求瀏覽器一方必須具備MFC的運(yùn)行時(shí)刻庫支持。總之，MFC對(duì)COM技術(shù)的支持在網(wǎng)絡(luò)應(yīng)用的環(huán)境下也顯得很不靈活。
后補(bǔ):
什么是ORM?
對(duì)象關(guān)系映射（Object Relational Mapping，簡(jiǎn)稱ORM）是一種為了解決面向?qū)ο笈c關(guān)系數(shù)據(jù)庫存在的互不匹配的現(xiàn)象的技術(shù)。簡(jiǎn)單的說，ORM是通過使用描述對(duì)象和數(shù)據(jù)庫之間映射的元數(shù)據(jù)，將java程序中的對(duì)象自動(dòng)持久化到關(guān)系數(shù)據(jù)庫中。本質(zhì)上就是將數(shù)據(jù)從一種形式轉(zhuǎn)換到另外一種形式。這也同時(shí)暗示者額外的執(zhí)行開銷；然而，如果ORM作為一種中間件實(shí)現(xiàn)，則會(huì)有很多機(jī)會(huì)做優(yōu)化，而這些在手寫的持久層并不存在。更重要的是用于控制轉(zhuǎn)換的元數(shù)據(jù)需要提供和管理；但是同樣，這些花費(fèi)要比維護(hù)手寫的方案要少；而且就算是遵守ODMG規(guī)范的對(duì)象數(shù)據(jù)庫依然需要類級(jí)別的元數(shù)據(jù)。
對(duì)象-關(guān)系映射（Object/Relation Mapping，簡(jiǎn)稱ORM），是隨著面向?qū)ο蟮能浖_發(fā)方法發(fā)展而產(chǎn)生的。面向?qū)ο蟮拈_發(fā)方法是當(dāng)今企業(yè)級(jí)應(yīng)用開發(fā)環(huán)境中的主流開發(fā)方法，關(guān)系數(shù)據(jù)庫是企業(yè)級(jí)應(yīng)用環(huán)境中永久存放數(shù)據(jù)的主流數(shù)據(jù)存儲(chǔ)系統(tǒng)。對(duì)象和關(guān)系數(shù)據(jù)是業(yè)務(wù)實(shí)體的兩種表現(xiàn)形式，業(yè)務(wù)實(shí)體在內(nèi)存中表現(xiàn)為對(duì)象，在數(shù)據(jù)庫中表現(xiàn)為關(guān)系數(shù)據(jù)。內(nèi)存中的對(duì)象之間存在關(guān)聯(lián)和繼承關(guān)系，而在數(shù)據(jù)庫中，關(guān)系數(shù)據(jù)無法直接表達(dá)多對(duì)多關(guān)聯(lián)和繼承關(guān)系。因此，對(duì)象-關(guān)系映射(ORM)系統(tǒng)一般以中間件的形式存在，主要實(shí)現(xiàn)程序?qū)ο蟮疥P(guān)系數(shù)據(jù)庫數(shù)據(jù)的映射。
面向?qū)ο笫菑能浖こ袒驹瓌t(如耦合、聚合、封裝)的基礎(chǔ)上發(fā)展起來的，而關(guān)系數(shù)據(jù)庫則是從數(shù)學(xué)理論發(fā)展而來的，兩套理論存在顯著的區(qū)別。為了解決這個(gè)不匹配的現(xiàn)象,對(duì)象關(guān)系映射技術(shù)應(yīng)運(yùn)而生。
讓我們從O/R開始。字母O起源于"對(duì)象"(Object),而R則來自于"關(guān)系"(Relational)。幾乎所有的程序里面，都存在對(duì)象和關(guān)系數(shù)據(jù)庫。在業(yè)務(wù)邏輯層和用戶界面層中，我們是面向?qū)ο蟮摹．?dāng)對(duì)象信息發(fā)生變化的時(shí)候，我們需要把對(duì)象的信息保存在關(guān)系數(shù)據(jù)庫中。
當(dāng)你開發(fā)一個(gè)應(yīng)用程序的時(shí)候(不使用O/R Mapping),你可能會(huì)寫不少數(shù)據(jù)訪問層的代碼，用來從數(shù)據(jù)庫保存，刪除，讀取對(duì)象信息，等等。你在DAL中寫了很多的方法來讀取對(duì)象數(shù)據(jù)，改變狀態(tài)對(duì)象等等任務(wù)。而這些代碼寫起來總是重復(fù)的
本文來自CSDN博客，轉(zhuǎn)載請(qǐng)標(biāo)明出處：http://blog.csdn.net/yanghao58686763/archive/2008/03/17/2192578.aspx