1、基于COM+的三層應用技術分析1. 系統功能11.1系統需求分析11.2小區物業系統的功能模塊12. 系統架構22.1兩層框架22.2三層架構22.3兩層和三層的優缺點33. COM+的由來和演變34. 在delphi中開發COM+組件54.1建立工程54.2編寫接口函數64.3注冊和安裝64.4設置調試65. COM+技術分析75.1概念分析75.2 COM+實現代碼分析：85.2.1 GUID8記錄類型8接口95.2.4 接口實現類105.2.5 COM+對象生成156. COM+的優缺點186.1COM+的優點186.2COM+的缺點181. 系統功能1.1系統需求分析一個小區的物業，負

2、責整個小區的管理。包含的內容有很多，包括對小區內所有的公共設備和建筑進行管理、維修；對小區內所有的單元戶進行信息統計；對小區內的入住人員進行管理；負責小區內的綠化和清潔；查收水電費和物業費；對小區內車輛進行統計，并收取停車費；提供投訴平臺，并進行處理；對小區內工作人員進行統計；對外來車輛的管理；對小區內工作人員的工資、休假等管理；設置小區的單位物業費用。1.2小區物業系統的功能模塊為了在短期內實現系統，體現開發和使用COM+組件以及三層架構的精髓，將小區物業的管理流程進行簡化。系統要實現的模塊如圖1.1所示。圖1.1系統功能模塊單元樓模塊實現：錄入小區內的樓棟信息，包括樓棟名稱、高度、一層的房

3、間數、占地面積等。修改小區內的樓棟信息。單元戶模塊實現：錄入小區內的單元戶信息，包括所在樓棟、所在高度、房間號、占地面積、名稱等。修改單元戶的信息，查找單元戶信息等。業主模塊實現：錄入入住人員的基本信息，包括姓名、性別、所在單元戶、入住時間、聯系電話和身份證號碼。修改業主信息、刪除業主信息，查找業主信息等。投訴模塊實現：錄入投訴信息、刪除投訴信息、修改投訴信息等。包括投訴時間、投訴人、投訴內容。報修維修模塊實現：錄入報修記錄，包括報修時間、報修內容。并可修改報修記錄。錄入微機記錄，包括維修時間、維修費用，可修改維修記錄。系統用戶模塊實現：添加一個系統用戶，包括用戶名、登錄名、登錄密碼。可刪除和

4、修改選定記錄。停車位和車輛模塊實現：錄入一個車位信息，包括所屬樓和車位編號。錄入車輛和車主信息，并對車輛和車主信息進行修改、刪除、查詢操作。添加一個車位的繳費信息。可查看某一個車位的歷史繳費記錄等。水電費和物業費模塊實現：每一個月，錄入所有單元戶的用電量、用水量、應繳電費、應繳水費、應繳物業費。并可對錄入信息進行修改、查詢。錄入每個單元戶的實際繳費記錄，并可修改、查詢。2. 系統架構2.1兩層框架 在數據庫開發中，兩層框架就是C/S模式。客戶機試應用程序，而服務器是數據庫服務器。數據庫用來存儲系統中的數據，而應用程序則負責連接數據庫，并擔當了顯示數據，處理用戶輸入數據，更新、保存保存數據到數據

5、庫的任務。也就是說，客戶機承擔了數據顯示和業務流程的所有任務。而數據顯示和整個系統的業務也是融合在一起，沒有明顯的分界線的。2.2三層架構 三層架構與兩層C/S相比，多了一個中間件。中間件也叫做應用程序服務器，中間件負責連接數據庫，更新并保存數據到數據庫，響應客戶端的請求并返回數據等。客戶端應用程序不再直接與數據庫連接，而是通過中間件關聯，并且所有的業務流程和數據處理都放置到中間件中。客戶端只用來顯示數據，與用戶進行交互。2.3兩層和三層的優缺點因為兩層架構的所有操作都集中到客戶端，導致兩層架構的客戶端比較龐大，并且更新系統要對所有的客戶端進行更新，不僅難于維護，維護成本也較高。當系統模塊中出

6、現重復的業務邏輯也要進行多次編程，代碼復用率較低。但是采用兩層架構有利于團隊間進行模塊化得開發，只要每個人負責一個或者多個模塊的數據顯示和業務處理。因為三層架構將數據顯示和業務邏輯分離，使得客戶端比較小，實現了瘦客戶機的結構。當每次更新和升級業務處理的時候，都可以只升級服務器端，降低了維護的成本和難度。此外，三層架構將所有的業務邏輯進行集中管理，提高了代碼的利用率（相同的業務流程，只需要進行一次編程，在不同的模塊中進行調用即可）。但是，與兩層架構相比，三層架構的系統也由它的不足之處。三層架構的中間層可以是以dll動態鏈接庫或者EXE可執行程序的形式存在，但不管是哪一種方式，都導致三層框架的系統

7、在編碼和調試的時候，更容易出錯。三層框架系統的速度和效率也低于兩層架構的系統。并且業務邏輯和顯示層也不容易分割，容易出現設計問題。Delphi的三層框架技術，也由一定難度，入門到完全掌握需要比較長得時間。3. COM+的由來和演變COM(component object model，組件對象模型)是客戶端和COM對象之間進行交流的一種二進制規范。這個規范允許用合適的語言把一些代碼編程一個組件，并且允許在編程語言中使用這個組件或功能，即使語言不通，也不會有問題，所以說COM是跨語言的，并且與編程語言無關。COM要實現的就是客戶和正在使用的COM對象的透明定位。而所謂的合適的語言是指：COM的跨語

8、言特性是狹隘的。理論上，COM生成的dll動態鏈接庫或者EXE可執行程序可以被任何語言所使用，但是一些非面向對象的編程語言，比如VB，就不能用來創建和使用COM對象。COM除了是一個二進制規范外，還是一種實現。它以一個COM庫和一組API函數的形式，提供了創建和管理COM對象的途徑。同時，它還可以說是一個服務，它為其他的應用程序提供了COM組件實現的接口函數。無論COM是以進程內（In-Process，dll動態鏈接庫的形式）COM還是以進程外（Out-Process，可執行程序的形式）COM的形式，都只能為本機內的應用程序提供服務，使用COM組件內的接口函數。為了解決COM在分布式上的缺陷，

9、使COM能夠在不同的計算機之間進行通信，Microsoft又研發了DCOM。DCOM（分布式COM）是對COM的進一步的擴展，一種無縫的擴充技術。DCOM使COM能夠支持在局域網、廣域網甚至Internet上不同計算機的對象之間的通訊。DCOM的跨計算機的特性，是因為DCOM封裝了網絡通訊的底層細節，使開發者致力于應用程序的業務邏輯開發。MTS（Microsoft Transaction Server，事務處理服務），它是Windows NT操作系統推出的一個中間件產品。Microsoft提出這個服務，是為了支出開發企業應用程序中多線程和分布式事務等復雜事務的處理，讓windows程序員開發以

10、組件為向導的分布式應用系統。MTS具備在同質和異質數據庫之間的數據進行Two phase commit的功能，允許大量的客戶端應用程序同時執行，并提供了數據庫事務的管理工作。將MTS和DCOM結合起來，很容易的就能開發出一個支持事務處理和多線程、并且保證能夠運行在同一臺或者不同的機器上的中間件作為一個系統的應用服務器。出現DCOM和MTS之后，開發分布式的系統的基本框架就可以采用如圖3.1所示的多層框架。圖3.1COM/MTS多層框架雖然MTS的出現，為COM提供了事務處理，安全控制，資源分發控制等服務，為COM開發提供了一個比較完整的系統結構。但是，因為歷史的原因，DCOM和MTS的優勢還不

11、為windows程序員所認識,DCOM和MTS也不能很好的進行融合。于是，在Windows 2000中，微軟引進了COM+的概念。COM+不是對COM的簡單升級，它幾乎包含了COM所有的功能，并且融合了DCOM和MTS的核心技術。也就說說，COM+不僅可以提供了客戶程序和COM+組件之間的透明定位，無論這個客戶程序和COM+組件是不是在一個計算機中，同時，COM+也提供了對事務的處理、事件機制、目錄和基于角色的安全機制等系統服務。COM+的出現使得開發一個三層框架的系統更加清晰和簡單。如圖3.2COM+三層框架。圖3.2 COM+三層架構4. 在delphi中開發COM+組件4.1建立工程在d

12、elphi的集成開發環境中，提供了創建COM+組件的模板。按照如下的七個步驟就能創建一個COM+組件的框架。1、 打開delphi集成開發工具2、 選擇File菜單下的Newother選項3、 在對話框中，選擇ActiveX頁面4、 選擇Transactional Object類型的工程，進行創建5、 在彈出的對話框中，輸入Coclass Name。6、 選擇線程模式為Aparment（默認）7、 選擇事務支持模式為Supports transactional。4.2編寫接口函數創建工程后，Delphi集成開發工具會自動創建三個文件。一個工程文件，一個類型庫文件，一個COM+接口實現類文件。在

13、delphi中編寫COM+組件十分容易，只要打開類型庫編輯器，在類型庫編輯器中，添加接口、接口函數、枚舉類型的變量或者記錄類型。在類型庫編輯器中所做的操作，都會直接反應到類型庫文件中。并且添加的接口函數的實現代碼也會添加到實現類文件中。程序員要做的，就是填充實現類中不完整（實際上時沒有一行代碼的空函數）的函數實現代碼，來完成系統的業務流程。4.3注冊和安裝編寫完COM+組件要實現的接口和服務之后，要為其他的應用程序提供服務還需要將COM+組件注冊到操作系統中。如果用delphi集成開發環境進行開發，可以選擇RUN菜單下的Register ActiveX Server選項，將COM+組件注冊到注

14、冊表中。此外，還可以運行windows提供的一個程序Regsvr32.exe 來注冊組件。接著將COM+組件安裝到操作系統的COM+應用程序中。選擇RUN菜單下的Install COM+ Objects選項。在對話框中選擇一個COM+應用程序，或者創建一個新的COM+應用程序。Delphi開發環境會自動將COM+組件添加到COM+應用程序中。之后，就能夠在組件服務中，找到我們開發的這個COM+組件。安裝COM+組件還有另外的一種方式就是，打開控制面板，進入管理工具。選擇組件服務，并打開COM+應用程序列表。右鍵通過向導建立一個新的COM+應用程序，并將建立的COM+組件添加到COM+應用程序中

15、去。4.4設置調試在客戶端應用程序調用COM+組件接口函數的時候，為方便調試，需要對COM+應用程序和工程進行設置。因為默認情況下，COM+是被自動調用和啟動的。設置過程如下：1、 在組件服務的COM+組件中，找到新添加的COM+組件應用程序。2、 設置該COM+應用程序的屬性高級頁面，選中在調試器中打開，并設置正確的調試路徑。3、 設置COM+工程。在Project菜單下，選中Options選項。4、 選中對話框的Link頁面。5、 選中EXE and DLL options下的兩個選項（include TD32 debug info和include remote debug symbols

16、）。6、 選中Run菜單下的Parameters選項。7、 選中對話框的Local頁面。8、 填寫Host Application為默認值，填寫Parameters為COM+應用程序的GUID值。這樣就能進行調試了。5. COM+技術分析5.1概念分析前面出現的概念有：接口、COM+組件，COM+應用程序。這三者之間的聯系如圖5.1所示：圖5.1接口、組件和COM+應用程序也就是說一個COM+組件是由接口構成的，它可以包含多個接口。而一個COM+應用程序可以封裝多個COM+組件。5.2 COM+實現代碼分析：前面一章節中講到在創建工程之后，就生成了一個類型庫文件，該文件以*_TLB命名。*為工

17、程文件的名稱，同時也會生成一個實現接口的類文件稱之為實現類文件。在類型庫文件中，定義了三個GUID和接口以及自定義的函數和記錄類型。而在實現類文件則包含了在類型庫文件中定義的所有接口函數的實現代碼。 GUIDGUID（Globally Unique Identifier，全球唯一標識符），是一個唯一性的標識符。在類型庫文件的一開始，就定義了三個GUID類型的常數。1、 LIBID_Server：代表了唯一的類型庫，它是COM+對象實現的類型庫的ID2、 IID_Iuptown代表了唯一的接口，是COM+對象的一個接口的ID3、 CLASS_uptown用于將COM+組件注冊到注冊表或者解除注冊

18、的時候起著關鍵性的作用，是生成COM+對象的重要標識符。記錄類型在類型庫編輯器中添加一個記錄類型，delphi集成開發環境就會在類型庫文件中自動添加對記錄類型的定義。舉例說明，在類型庫編輯器中添加一個記錄類型的變量并命名為Build，為這個記錄添加多個字段并設置每個字段的類型。點擊刷新按鈕后，在類型庫文件中，就能看到剛剛添加的記錄類型的定義。Build = packed record b_ID: Int64; b_name: WideString; b_address: WideString; b_high: Int64; b_home: Int64; b_size: Double; b_li

19、ft: WideString;end;首先，這個記錄類型與我們在delphi中自己定義的記錄類型的區別是，多了一個packed的關鍵字。在delphi中，為了加快取記錄類型變量各個字段的速度，進行了這樣的優化：變量都是字節對齊的方式。所以會出現sizeof操作出來的結果和記錄類型的變量大小不一樣的情況。而packed關鍵字要求對記錄類型進行壓縮，也就是說避免了delphi對記錄類型的優化。這么做不進節省了空間，更重要的是保證了不同的程序進行通信的時候不出錯。正是因為COM+組件允許不同的進程調用它提供的服務（接口函數），該記錄除了使用packed進行壓縮外，每個變量的類型也與一般的delphi

20、應用程序有區別。比如用WideString代替String或者shortstring類型，用Int64代替Interget類型。事實上，在編寫COM+組件的時候，不管是函數或者過程的參數還是記錄類型的變量等，所有的對外變量都采用特殊的參數類型。這么做的好處是使得與其他進程進行通信的時候，互相兼容。接口COM+組件的基礎就是接口。編寫COM+組件最重要也是編寫COM+組件中的接口和接口中的函數。那么什么是接口呢？接口類似于delphi中的抽象類。因此不能定義一個接口的實例。但與抽象類的區別是，接口僅僅包含了一組實現不同功能的函數和過程，卻不能定義變量。也不能對接口中的函數限定范圍。所有的函數和過

21、程都默認是public的，不存在private或者protect等修飾。并且接口是用關鍵字interface定義的，而不是用class。下面就是一個接口的定義：Iuptown = interface(IDispatch) 'CE8179DC-5579-4C47-BBFF-0CA70D28541E' function ConnectToDB: WideString; safecall; function ExecSQL(const sqlString: WideString): OleVariant; safecall; function DisConnect: WideStri

22、ng; safecall; function InsertToBuild(BuildbRecord: Build; out outString: WideString): Int64; safecall; function InsertToHome(HomeRecord: Home; out outString: WideString): Int64; safecall; function InsertToPeople(PeopleRecord: People; inHomeDate: TDateTime; out outString: WideString): Int64; safecall

23、; function SetParameter(const p_name: WideString; const p_value: WideString; var outString: WideString): Int64; safecall; function InsertToCar(CarRecord: Car; out outString: WideString): Int64; safecall; function UpdateCarUse(CarRecord: Car; out outString: WideString): Int64; safecall; ··&

24、#183;···從接口函數的聲明中可以看到，每個函數都有safecall標注。原因是：普通函數都是采用register寄存器調用方式，delphi為register調用方式的函數的參數提供最多三個寄存器，用來提高函數調用的速度，超過三個的參數則采用堆棧方式。并且register調用采用從左到右的順序對參數進行賦值。而COM接口默認的方法調用時stdcall標準調用，即使全部參數采用堆棧方式的調用形式來保持COM的跨語言兼容性。而COM+組件中的接口，是雙重接口。在類型庫編輯器中，定義一個函數的時候，所有的函數返回值都默認為HResult。這是自動化對象中所有函數都

25、要符合的一個規則。要創建一個想要有返回值的函數，就將參數定義為out類型，或者將最后一個參數的返回值設定為函數名稱，類型為out+Refval類型。采用這種方式定義的函數可以捕捉異常，即使是方法中未被處理的異常，也可以被外套處理并通過HReuslt返回給調用者。在定義COM+組件的時候，要捕捉函數調用的異常，必須使用函數OLECheck進行檢查。另外，windows中，標準的調用順序都是從右到左的。 接口實現類接口只有虛函數，并且不能創建變量。要實現接口的函數，就是生成一個接口的實現類。這個實現類繼承了一個對象類（Tobject的派生類），并包含一個或者多個接口。小區物業管理系統的實現類定義如

26、下：Tuptown = class(TMtsAutoObject, Iuptown) private con: TADOConnection; function ConnectToDB: WideString; safecall; function DisConnect: WideString; safecall; protected function ExecSQL(const sqlString: WideString): OleVariant; safecall; function InsertToBuild(BuildbRecord: Build; out outString: Wid

27、eString): Int64; safecall; function InsertToHome(HomeRecord: Home; out outString: WideString): Int64; safecall; function InsertToPeople(PeopleRecord: People; inHomeDate: TDateTime; out outString: WideString): Int64; safecall;······ public procedure initialize; override;

28、destructor Destroy; override;從delphi的集成開發環境中，可以看到小區物業管理系統中COM+組件的接口實現類Tuptown的繼承關系如圖5.2所示：圖5.2實現類的繼承關系 父類的含義1、TComObjectTComObject實現了IUnknown、ISupportErrorInfo、標準的COM聚集支持和一個對應的類工廠支持。如果我們想創建一個輕量級的可連接客戶端的基于IUnknown接口的COM對象的話，COM對象就應該從TComObject 類繼承。 2、TComObjectFactoryTComObjectFactory 是同TComObject對象配

29、合工作的。它把對應的TComObject 公開為CoClass。TComObjectFactory 提供了CoClass的注冊功能(根據CLSIDs、線程模式、應用程序ID等)。還實現了IClassFactory 和 IClassFactory2 接口以及標準的COM 對象許可證支持。簡單地說如果要想創建TComObject對象，就會同時需要TComObjectFactory對象。3、TTypedComObjectTTypedComObject等于TComObject 和對IProvideClassInfo接口的支持。IProvideClassInfo 是自動化的標準接口用來公開一個對象的類型

30、信息的（比如可獲得的名字、方法、支持的接口等，類型信息儲存在相關的類型庫中）。TTypedComObject 可以用來支持那些在運行時能夠瀏覽類型信息的客戶端，比如Visual Basic的TypeName 函數期望一個對象能夠實現IProvideClassInfo 接口，以便通過類型信息確定對象的文檔名稱（documented name）。4、TTypedComObjectFactoryTTypedComObjectFactory 是和TTypedComObject配合工作的。就等于TComObjectFactory + 提供緩存了的TTypedComObject類型信息（ITypeInfo

31、）引用。一句話，創建TTypedComObject必然會同時創建TypedComObjectFactory 類工廠。5、TAutoObjectTAutoObject 等于TTypedComObject+實現IDispatch接口。TAutoObject適用于實現支持自動化控制的COM對象。6、TAutoObjectFactoryTAutoObjectFactory顯然是同TAutoObject密不可分的。它等于TTypedComObjectFactory +提供了TAutoObject的接口和連接點事件接口的緩存類型信息 (ITypeInfo)。7、TMtsAutoObjectDelphi幫助

32、文檔中，是這么描述TMtsAutoObject類的：TMtsAutoObject是MTS應用程序服務器的MTS對象和接口的裝載器。而MTS自動化對象是那些完成了IObjectControl接口的雙重接口自動化服務器。MTS自動化對象將MTS的事物處理、安全機制等特性和自動化對象的特征融合在一起。從這段話中，可以看出，所有的MTS對象都是要完成IObjectControl接口的。 IUnknown接口從圖中可以看出，所有的接口的祖先都是IUnknown接口。IUnknown是定義在system.pas文件中的一個接口。它的定義如下：type IInterface = interface '

33、;00000000-0000-0000-C000-000000000046' function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall; function _AddRef: Integer; stdcall; function _Release: Integer; stdcall; end; IUnknown = IInterface;可以看到，IUnknown接口包含了三個函數。因為接口所有的函數都是公共的虛函數，所以這三個函數都是由IUnknown的派生類來實現的。1、 QueryInterface函數

34、：返回某個COM對象中的接口指針的函數。從圖上可以看出，一個類可以繼承一個父類和多個接口，并且一個COM對象可以聚合多個內部接口。如果在應用程序中，使用COM對象沒有定義或者包含的接口，就會提示接口不存在等錯誤信息。因此使用一個接口前可以使用QueryInterface函數判斷某一個COM對象是否包含了將要使用到的接口。調用該函數的時候，輸入參數是某個接口的ID（IID），當該COM對象實現了要查找的接口的時候，就返回數值S_OK（數值0），而如果沒有找到該接口，則返回數值E_NOINTERFACE （數值HRESULT($80004002)）。2、 _AddRef函數：接口是引用計數的。當客

35、戶端從COM對象中獲得一個接口時，該函數就增加了一個接口的引用計數。3、 _Release函數：而當客戶端釋放了接口調用時，該函數釋放掉一個了接口的引用計數。這三個函數的實現，定義在類TComObject中。詳細如下：TComObject = class(TObject, IUnknown, ISupportErrorInfo) Private······FRefCount: Integer;······ protected IUnknown function IUnknow

36、n.QueryInterface = ObjQueryInterface; function IUnknown._AddRef = ObjAddRef; function IUnknown._Release = ObjRelease; IUnknown methods for other interfaces function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall; function _AddRef: Integer; stdcall;function _Release: Integer; stdcall;

37、83;·····Publicfunction ObjAddRef: Integer; virtual; stdcall;function ObjQueryInterface(const IID: TGUID; out Obj): HResult; virtual; stdcall;function ObjRelease: Integer; virtual; stdcall;······需要提到的是，因為聚合的原因，使得一個IUnknown的派生類中，可能包含了同名的接口函數。如果這些接

38、口函數的實現是相同的，就定義一個共同的方法。但如果是不同的實現函數，就需要使用到方法分辨子句。在TComObject類的定義中，function IUnknown.QueryInterface = ObjQueryInterface; function IUnknown._AddRef = ObjAddRef; function IUnknown._Release = ObjRelease;這三條語句就是方法分辨語句。當調用IUnknown的三個函數的時候，實際上是在執行ObjAddRef、ObjRelease、ObjQueryInterface這三個函數。ObjAddRef和ObjRelea

39、se函數共同維護了接口的引用計數變量FRefCount，承擔了COM+組件的生存期。這兩個函數和變量FRefCount只在控制COM+組件的生存期的時候才有用，其他時候完全沒有意義。在delphi編程中，可以不用考慮這兩個函數的調用，系統會自動管理FRefCount變量。但是一旦脫離了delphi，就需要程序員自己調用_AddRef 和_Release函數來管理COM+組件的生存期。 創建接口的函數在創建工程的一開始，就輸入了一個CoClass name。這個名字，在*_TLB文件末尾出現。Couptown = class class function Create: Iuptown; cla

40、ss function CreateRemote(const MachineName: string): Iuptown; end;用delphi集成開發環境創建的每一個COM+接口，都會有一個對應的CoClass與之對應。這個CoClass是系統自動生成的，用來創建接口的函數。它提供了兩個函數，一個用來創建本地COM+組件接口，另一個用來創建遠程的COM+組件接口。這兩個函數調用了操作系統中的動態鏈接庫函數，并使用olecheck函數來判斷是否接口創建成功。詳細的內容將在COM+是如何啟動的那一章節中講述。現在需要知道的是，CoClass的兩個函數，在COM+對象的創建中，起了關鍵的作用。

41、COM+對象生成用來創建COM+對象的接口的函數，已經清楚了。那么接口實現類是如何創建并和接口聯系在一起的呢？COM+對象的創建和初始化，都在接口實現類文件最后的initialization部分。initialization部分是delphi用于初始化的特殊部分。當程序啟動后，會先行調用這部分的代碼進行初始化。小區物業管理系統服務器的初始化代碼如下：initialization TAutoObjectFactory.Create(ComServer, Tuptown, Class_uptown,ciMultiInstance, tmApartment); ComServer：TComServe

42、r。ComServer是定義在ComServ單元的全局變量。該變量是用來注冊和撤銷注冊COM+服務的對象。 Tuptown是程序員自己創建的接口實現類。 Class_uptown是GUID類型的常量。將COM+注冊到注冊表的HKEY_CLASSES_ROOT/CLSID目錄下，就要用到Class_uptown常量值。 ciMultiInstance是服務器的實例模式。COM+組件服務器，可以有以下三種實例模式，默認為Mulitple Instance方式。1、Internal：供COM對象內部使用，不會響應客戶端的請求，只能通過COM對象內部的其他方法建立。2、Single Instance：

43、不論當前系統內部是否存在相同COM對象，都會建立一個新的程序及獨立的對象實例。3、Mulitple Instance：如果有多個相同的COM對象，只會建立一個程序，多個COM對象的實例共享公共代碼，并擁有自己的數據空間。 tmApartment是COM+服務器的線程模式。COM+服務器的線程模式一下五種：1、Single：僅單線程，處理簡單，吞吐量最低；2、Apartment：COM程序多線程，單個COM對象處理請求單線程；3、Free：一個COM對象的多個實例可以同時運行。吞吐量提高的同時，也要求對COM對象進行必要的保護，以避免多個實例沖突；4、Both：同時支持Aartment和Free

44、兩種線程模式。5、Neutral：只能在COM+下使用。在這個函數里面，可以看到建立工程的時候所選擇的線程模式等服務器特征最終都是以代碼的形式控制和實現的。前面已經提到了TAutoObjectFactory類，它是創建TAutoObject類對象的工廠類。TAutoObjectFactory的create函數遞歸調用了它的父類的工廠類的create函數，并進行初始化。這個函數提供了創建COM+對象所需要的所有的信息。在TComObjectFactory.Create函數中，有這么一句話：ComClassManager.AddObjectFactory(Self)。這個函數的作用，就是將創建的COM+對象加入到COM的管理器中進行管理。 初始化程序又是怎么被調用的呢？客戶端調用CoClass的create或者CreateRemote函數用來返回一個COM+對象的接口。