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