我是否需要使用COM（組件對象模塊）

幾天前我開始閱讀COM。然後，我的一位團隊成員告訴我們這是一項舊技術，現在還沒有人使用這種技術。我是否需要使用COM（組件對象模塊）

我的問題是：

1）如果是一個老技術，那麼什麼是對的選擇。

2）爲什麼我不需要使用COM。即COM的缺點是什麼？

2012-11-22 Umesha MS

你讀過關於COM的任何內容嗎？像[維基百科頁面]（http://en.wikipedia.org/wiki/Component_Object_Model）？ COM可能是「老」的，但它仍然是Windows工作方式的基礎。例如，如果您想訪問Excel工作表，則必須使用COM。 –

如果您使用的是.net技術，您可能不需要使用COM –

COM對於大多數用途來說過於複雜，因爲它試圖解決大多數人沒有的問題 - 例如跨機器的對象或與VB的互操作性。 –

COM是一種'老技術'，就像C++一樣。僅僅因爲它太舊並不意味着它已經過時。微軟不斷回到它的原因（Windows 8大量使用它）是因爲它是一個相對低開銷的基於對象的技術。在使用COM之前，沒有大的運行時間來初始化（儘管一個組件可以在需要時初始化運行時間，例如... NET CCW）。

接口/實現邊界保持嚴格分離，因此它對於以面向對象方式公開Windows功能（以及Windows Shell基於COM的DirectX）非常有用。

COM遭受了一般人對什麼是COM和什麼建立在COM之上的誤解。 ActiveX，DCOM，OLE，COM +等都建立在COM上，但是沒有定義COM是什麼。 COM本身作爲核心技術一直保持相對簡單。

我說相對來說因爲COM並不完美。公寓模型可能導致重大問題，例如需要應用程序抽取消息隊列的跨公寓編組。早在九十年代後期，人們就開始瘋狂地將所有東西都從COM組件中解放出來，並且在應用程序中造成了不必要的複雜性。但是，這是一種經過良好測試的技術，使用得當時它運行良好，尤其是對於第三方暴露或消費功能。如果你想真正理解Windows API，你需要知道COM如何工作。

來源

2012-11-22 14:32:41 snowdude

1）如果是舊技術，那麼有什麼選擇。

COM肯定老了。微軟的「替代品」是.NET，但意味着你需要與CLR一起玩（所以本機C++不會玩，你需要C++/CLI來實現）。最新的選擇現在稱爲WinRT（Windows運行時）。 WinRT目前僅適用於Windows 8和Windows Server 2012.在最低級別上，WinRT實際上是COM，但微軟已經重新考慮了其許多缺陷。平臺/語言不可知的替代方案包括Google協議緩衝區，Apache Thrift和SOAP。

2）爲什麼我不需要使用COM。即COM的缺點是什麼？

COM的主要用途是進程間通信（IPC）。例如，如果您有兩種應用程序用兩種編程語言編寫並希望它們進行通信，則COM是一個（特定於Windows的）解決方案。 COM在90年代被廣泛用於C++和VB6應用程序之間的通信。如果你不需要IPC，那麼你的COM前景非常低。今天我們最常使用COM來在本地C++應用程序和用C＃編寫的託管.NET應用程序上執行IPC。

來源

2012-11-22 04:29:36

「我們今天在工作中最常用的COM是做IPC」DirectX是COM，你知道。 – SigTerm

我們在工作中並沒有對DirectX做任何事情，所以我不確定這個語句對引用文本的重要性。而且，在COM上執行DirectX仍然可以被認爲是IPC，是的？另一個進程恰好是一個OS庫。 –

@BretKuhns，沒有IPC和系統調用的COM，實際上很多。除非你認爲一個簡單的完全用戶空間函數調用是IPC。 COM確實是用於VB6組件的（我寧願說它是_chosen_），但它並不是與C++代碼進行通信的唯一方式，您始終可以導出DLL函數並公開函數地址。 – acelent

最新的大型微軟「技術」，用於編寫windows 8 metro應用程序（無論它們現在被稱爲......）的WinRT運行時完全依賴於COM，所以它當然不會過時。

來源

2012-11-22 15:19:37 jcoder

我是否需要使用COM（組件對象模塊）

回答

相關問題