如何理解.NET框架與COM的背景和歷史以及關系的發展

今天就跟大家聊聊有關如何理解.NET框架與COM的背景和歷史以及關系的發展，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

.NET框架與COM：背景和歷史

可復用軟件不是一個新概念。八年來，人們一直在使用各種形式的組件對象模型(COM)。事實證明，它是最為成功的可復用軟件模型。COM引進了“組件”的概念——它是可復用的代碼塊，可以將多個獨立函數的功能進行組合，從而擴充成諸如Microsoft Word這樣的應用程序。

大多數開發人員使用OLE時深刻體驗了COM功能。OLE是基于COM形成的一組功能，使得用戶能將一種文檔嵌入到另一種文檔中。這個功能本身似乎不太引人入勝，但它的作用卻不同凡響：當用戶將一個Excel文檔粘貼到Word文檔中后，單擊嵌入的Excel文檔時，OLE將會把Word的工具欄和菜單轉換成Excel的工具欄和菜單。

從開發人員的角度看，COM通過引進幾個明確定義的接口（諸如iUnknown）便可提供代碼復用功能，開發期工具可通過這些接口來查詢一個組件的功能，并能把這些功能添加到工具中。這就像Visual Basic?開發系統工具箱中的控件能夠被拖到某個窗體中一樣。實際上，每個控件都代表上百行甚至上千行的代碼，可以容易地封裝在“黑匣子”中，開發人員只需直接調用其功能即可。

開發人員在使用COM時感到不便的一個問題是，他們必須編寫附加代碼來將業務邏輯程序轉換成可復用的組件，同時還必須實現許多接口才能進行這種轉換。最重要的是，COM要求開發人員必須手動處理復雜問題，比如：清空不再使用的組件曾占用的內存、計算組件的使用次數、建立或撤消線程和進程以及處理版本控制問題等。

有人可能認為，讓開發人員親自執行這類工作的主意非常好，但這也有幾個弊端。首先，要開發人員一一執行上述所有工作非常困難，往往容易出錯：導致應用程序錯誤、系統崩潰以及可怕的“DLL Hell”。另外，嚴格地寫出所有這種附加代碼，會降低開發人員的工作效率，導致延期上市。

這對使用Visual C++?開發系統的開發人員來說，尤其如此。而對使用Visual Basic的開發人員來說，這種情況不是很嚴重。Visual Basic抽象并簡化了COM的許多概念，是全世界***生產力、***的開發環境，但它的局限性在于：為了實現這種高生產力而不得不向開發人員屏蔽了COM的一些功能。

微軟在2000年的專業開發人員大會（PDC）上引進的.NET框架，能自動在軟件編寫過程中進行“智能拼接”，使得開發人員可以集中精力編寫業務邏輯，而不必編寫COM基本結構。

什么是.NET框架？

.NET框架是一個多語言組件開發和執行環境，它由以下三個主要部分組成：

公共語言運行時。此名稱不能準確反映它的全部功能。實際上，公共語言運行時在組件的開發及運行過程中，都扮演著非常重要的角色。在組件運行過程中，運行時負責管理內存分配、啟動或刪除線程和進程、實施安全性策略、同時滿足當前組件對其它組件的需求。在開發階段，運行時的作用有些變化：與現今的COM相比，運行時的自動化程度大為提高（比如可自動執行內存管理），因而開發人員的工作變得非常輕松。尤其是，映射功能將銳減開發人員將業務邏輯程序轉化成可復用組件的代碼編寫量。對編程語言而言，運行時這個概念并不新奇：實際上每種編程語言都有自己的運行時。Visual Basic開發系統具有最為明顯的運行時（名為VBRUN），Visual C++?跟Visual FoxPro?、Jscript?、SmallTalk、Perl、Python和Java一樣有一個運行時，即MSVCRT。.NET框架的關鍵作用在于，它提供了一個跨編程語言的統一編程環境，這也是它能獨樹一幟的根本原因。

統一的編程類。.NET框架為開發人員提供了一個統一、面向對象、層次化、可擴展的類庫集(API)。現今，C++開發人員使用的是Microsoft基類庫，Java開發人員使用的是Windows?基類庫，而Visual Basic用戶使用的又是Visual Basic API集。只是簡單地一用，.NET框架就統一了微軟當前的各種不同類框架。這樣，開發人員無需學習多種框架就能順利編程。遠不止于此的是，通過創建跨編程語言的公共API集，.NET框架可實現跨語言繼承性、錯誤處理功能和調試功能。實際上，從JScript到C++的所有編程語言，都是相互等同的，開發人員可以自由選擇理想的編程語言。

活動服務器頁面(ASP+)。ASP+是使用.NET框架提供的編程類庫構建而成的，它提供了Web應用程序模型，該模型由一組控件和一個基本結構組成。有了它，Web應用程序的構建變得非常容易。開發人員可以直接使用ASP+控件集，該控件集封裝了公共的、用于超文本標識語言(HTML)用戶界面的各種小器件（諸如文本框、下拉菜單等等）。實際上，這些控件運行在Web服務器上，它們將用戶界面轉換成HTML格式后再發送給瀏覽器。在服務器上，控件負責將面向對象的編程模型提供給Web開發人員，這種編程模型能提供面向對象編程技術的豐富功能。ASP+還提供一些基本結構服務（諸如會話狀態管理和進程重啟服務），這些服務大大減少了開發人員要編寫的代碼量，并使應用程序的可靠性得到大幅度提高。ASP+還允許開發人員將軟件作為一項服務來提供。通過使用ASP+ Web服務功能，ASP+開發人員只需進行簡單的業務邏輯編程，而由ASP+基本結構負責通過簡單對象訪問協議(SOAP)來提供服務。

.NET框架與COM的關系

.NET框架的一個主要目的是使COM開發變得更加容易。COM開發過程中最難的一件事是處理COM基本結構。因此，為了簡化COM開發，.NET框架實際上已自動處理了所有在開發人員看來是與“COM”緊密相關的任務，包括引用計算、接口描述以及注冊。

必須認識到，這并不意味著.NET框架組件不是COM組件。事實上，使用Visual Studio 6.0的COM開發人員可以調用.NET框架組件，并且在他們看來，后者更像是擁有iUnknown數據的COM組件。相反，使用Visual Studio.NET的.NET框架開發人員則將COM組件視作.NET框架組件。

為了避免引起誤解，這里需對這種關系加以特別說明：COM開發人員必須手動去做大多數.NET框架開發人員可以在運行時自動執行的事情。例如，必須手寫COM組件的安全性模塊，且無法自動管理模塊占用的內存，而在安裝COM組件時，注冊條目必須放進Windows注冊表中。對.NET框架而言，運行時實現了這些功能的自動化。例如，組件本身是自我描述型的，因而無需注冊到Windows注冊表中便能安裝。

.NET框架與COM+的關系

當把COM與Microsoft事務服務器(MTS)和分布式COM(DCOM)結合在一起時，就變成了COM+。COM+提供了一組面向中間層的服務。特別是COM+提供了進程管理功能和數據庫與對象連接池處理功能。在將來的版本中，它還將提供一種稱為分區的功能——專門為應用程序服務提供商設計的更強大的進程隔離功能。

COM+服務主要面向中間層應用程序開發，并主要為大型分布式應用程序提供可靠性和可擴展性。這些服務是對.NET框架所提供服務的補充；通過.NET框架類，可以直接訪問這些服務。

看完上述內容，你們對如何理解.NET框架與COM的背景和歷史以及關系的發展有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。