COM, COM+ and .NET 的區別

所有的優秀程式員都會盡自己的最大努力去使自己所寫的程式具有更好的可重用性，因為它可以讓你快速地寫出更加健壯和可升級性的程式。

　　有兩種使代碼重用的選擇：

　　1．白盒：最簡單的一種，就是把你的程式片拷貝到另一個檔案中。
　　2．黑盒：它包括把編譯過的程式片串連起來。因此用戶端可以調用的編譯過的黑盒類庫就叫作組件。

　　.Net中也同樣為開發人員提供了類似於COM的建立和展開組件的方法。開發人員很容易地被這兩種以組件為基礎的開發模型所迷惑，所以，讓我們來看一看這些不同的開發方法，以使我們消除疑惑。

　　COM的產生

　　在以前程式設計過程中，程式員把它們的函數庫放在一個叫做目標(Object)檔案的單獨檔案中，在這些檔案中，包含了編譯過的代碼。當程式員要使用一個特別的目標檔案的時候，他們把客戶程式編譯成機器代碼，然後依靠動態連結的手段把客戶程式聯結到目標檔案上，最後變成一個單一的可執行檔。這種作法的唯一的好處在於它節省了編譯函數庫的時間。但是它有許多的缺點，比如由於在每個單獨的可執行檔中都有一個程式庫包括在裡面，浪費了許多儲存空間；對應用程式的維護也是非常困難的，如果在函數庫中發現了一個bug，整個可執行檔都要被重新編譯和分發。

　　還有不只一個的嚴重的限制在裡頭，一個客戶應用程式必須要和用同一種語言編製的函數庫在一起才能使用。比如說，一個用QuickBasic寫的客戶應用程式就不能引用一個用C++寫的函數庫。

　　因此，微軟公司出品了COM，COM僅僅只是一個規範。不管組件用什麼語言寫成，只要符合這個COM規範，就能被用任何一種語言寫成的客戶程式調用。此外，程式員不必再擔心要去建立一個單一的可執行檔，因為組件是以GUID（Global Unique Identifier全球唯一識別碼）來標識的。GUID是一個128位的號碼，和一些相關的資訊一起被放在系統的註冊表中，用來唯一標識組件。客戶應用程式只在運行期間才動態地建立一個組件的執行個體，並使用這個組件的功能，因此，只需要一個函數庫的拷貝。它的缺點就是大家常常提到?quot;DLL地獄"。這個問題在一個DLL要被一個新版本的DLL所取代時引發。開發人員不得不通過關閉所有的客戶應用程式的方法（如果不行，還要關閉WWW服務）來達到清除所用對這個組件的引用的目的。有時所有的方法都還起不了作用，那你只好重新啟動伺服器後才能替換掉老的DLL。

　　COM+

　　為了讓企業級的應用程式能使用上COM，它必需要有以下的特定的能力。

　　· 驗證能力
　　· 對象池（Object Pooling）
　　· 交易處理
　　· 支援分布式架構

　　為了使開發人員不必去為他們的組件添加這些能力，微軟公司出品了DCOM（Distributed COM分布式COM）和MTS（Microsoft Transaction Server微軟事務伺服器）。使用這兩種技術，開發人員就可以把精力用在他們的商業邏輯上，而不必放在背景他們的組件上。

　　DCOM是一個用於分布式的組件之間的通訊的RPC（Remote Procedure Call）協議。用戶端向一個本地機的代理類發送請求，然後由代理類將這個請求隱含地給安裝在遠程機器上的"根"類，然後執行結果原路送回給代理類，最後代理類把它們回送給用戶端。因此，客戶程式的位置完全與組件的位置無關。DCOM的缺點在於，由於DCOM使用的是一個獨立的硬體連接埠，而不是HTTP協議的80連接埠，所以在組件間通訊的過程中，必須保證這個連接埠是開著的。這是一個嚴重的安全問題。所以DCOM不能夠輕易地穿越防火牆。

　　為了使用MTS，程式員在它們的組件裡放置特別的MTS鉤子，編譯後把他們放在MTS包中。把有關係的組件放在一個單一的包中有它自己的好處。當客戶請求一個包中的一個組件的一個執行個體的時候，MTS確保為這個包建立一個新的專門的線程，一個新的組件執行個體被建立在這個線程上並被應用事務服務。至於對象池服務和安全服務是否要被建立，那就要看開發人員的請求了。

　　MTS允許相關的作業單元被當作一個事務來對待，這意味著如果所有的作業單元被成功地完成，整個事務就被當作成功地完成，反之如果有一個單元未成功完成，整個事務將被重新輪迴。

　　在客戶請求對象和釋放對象後，MTS仍儲存著這個對象，所以當另一個客戶請求同一個組件的時候，MTS就將儲存著的對象交給它。通過這種方式，MTS減少了在伺服器源執行個體化的次數。

　　MTS允許開發人員用安全措施來組裝他們的組件，以使其具有識別請求它的服務的客戶的能力。這能夠確保未經授權的客戶不能夠使用組件的功能。

　　MTS以COM+的名義被完整地整合到了微軟公司的Windows 2000作業系統中，但是COM+不僅僅只有MTS，它還包括一些其它的服務。MSMQ（Microsoft Message Queue Server），一個與MTS一同發布的服務，也被以COM+的名義整合到了Windows 2000中。MSMQ允許伺服器端和用戶端進行同步的通訊。事件服務（Event Service）也被加了進來，它使伺服器能夠與用戶端同步地交流事件的發生。Server Load Balancer服務（Load Balancing）自動地執行個體化機器上的具有最多資源的伺服器上的請求對象。

　　.NET

　　.Net提供了一種全新的建立和展開組件的方法。它就是大名鼎鼎的Assemblies。使用COM，開發人員必需要在伺服器上註冊組件，這也就是說，系統註冊表中的組件的資訊必須被更新。這樣做的目的是保證組件的中心位置，以使COM+能夠找到合適的組件。使用.Net的Assemblies，裝配（Assembly）檔案把所有需要的中繼資料（meta data）都壓入一個叫Manifests（名單）的一個特殊的段中。在.Net中，要使assembly對使用者有效，只要簡單地把他們放在一個目錄中就行了。當客戶程式請求一個特別的組件的執行個體的時候，.Net運行期（runtime）在同一個目錄搜尋assembly，在找到後，分析其中的manifest，以取得這個組件所提供的類的資訊。由於組件的資訊是放在manifest裡的，所以開發人員就沒有必要把組件註冊到伺服器上，因此，就可以允許幾個相同的組件安全地共存在一個相同的機器上了。

　　建立一個.Net assembly並不像建立一個VB6組件，唯一讓開發人員操心的就是商業邏輯，所有的後台代碼全部由.Net運行期產生，而且由於.NET運行期具有片段收集器的功能，組件不必擔心它的引用數目（在COM中是靠Iunknown的協助）。簡單地說，在.NET中建立一個assembly比建立一個VB6 COM要簡單地多。

　　純的.NET assemblies不能夠在COM+服務下註冊，因為它們是和COM不同的二進位標準。面對.NET，assemblies的前景相對於COM來說是"進階的COM"。但是由於當前架構於COM+上的應用程式的可靠性，COM還會持續一段時間。這也許就是微軟公司向開發人員同時提供開發.NET assemblies和COM的工具的原因吧。

　　類型庫引入器(Type Library Importer (TLBIMP.exe))工具可以把COM組件封裝成.NET，以使以前的東西可以在.NET應用程式中繼續使用。

　　類型庫匯出器（Type Library Exporter (TLBEXP.exe)）工具將.NET組件封裝成COM，這個工具也是很有用的，如果你要用你的.NET assemblies去替換原有的COM組件，就得用到它了。由COM+提供的服務不能被忽略，所以把.NET assemblies封裝成COM組件就變得相當重要了。作為一種選擇，開發人員可以從.NET基礎類庫中選擇更多的功能。