COM +庫應用程序的目的是什麼？

Question

當一個COM +應用程序創建嚮導提供一個圖書館和一個服務器應用程序之間進行選擇。

服務器應用程序是在一個單獨的過程被激活，這可用於廉價地互操作的64位消費者提供32位的進程內COM組件。

什麼用的庫的應用程序被激活就在主叫過程？爲什麼使用它們而不是普通的舊式COM服務器？

Answer 1

有以下幾種：

1. 性能 - 這是因爲你沒有去通過信息自動化（打包和解包）

2. 隔離快一點 - 如果許多不同的應用正在使用該庫，然後每個都有自己的副本。與和STA（單線程模型）的MTA（多線程單元）之間的區別時，這一點是最重要的

進程內服務器（這實在是一個不折不扣的過程，出來的呼叫者的過程）是由所有不同的來電者共享（這是有便宜的IPC/RPC）

好吧，我多帶幾個定義編輯，並略偏引用一個偉大的方式：

1. 上下文真的是所有使用對象的狀態。
2. 因果關係是非常喜歡概念表示在上下文中使用的對象的線程。 （「因果關係是COM方法調用的分佈式鏈，其跨越任何數量的過程中的任何數量的上下文」） - 來自ISBN：0-201-61594-0）

那些概念在約30從蒂姆·埃瓦爾德的優秀圖書「事務性COM +」 ISBN章2頁：0-201-61594-0

因此，採取直接引自第2章的總結： 「對象可以使用對象上下文與它的上下文交互並使用調用上下文給出一個給定的因果關係，這兩個對象提供了與COM +運行時服務交互的接口，這種編碼風格「深入上下文」使得COM +的開發與經典的COM開發有很大的不同。

最後，第2章有一個討論「爲什麼庫應用程序？」， （這是從你的問題，爲什麼不只是普通的老式COM有什麼不同？） 他的論點主要是表明利用COM對象相同的原因， 1.每個應用程序都有自己的實例。 2.加載到非DLLhost.exe進程。 3.少開銷。 4.簡單部署通用對象。

因此，底線是，如果你不分配，不能交易的性質，因此可能沒有真正的優勢，使用COM + COM上。但是，如果您編寫COM +應用程序並將其作爲LIBRARY應用程序進行部署，則它的行爲會更像COM組件。

希望有所幫助。

Answer 2

主要目的是從COM+ application contexts受益。

CoGetObjectContext爲IObjectContext或IObjectContextActivity將從純在進程組件返回E_NOTINTERFACE，而這將成功地在一個COM +庫應用程序（當然服務器應用程序）工作。

對於ISecurityCallContext，安全上下文也可通過CoGetCallContext獲得。

它與性能或隔離無關。

作爲站點說明，檢查COM +庫應用程序可用的一種方法是運行dcomcnfg.exe導航到組件服務，計算機，我的電腦，COM +應用程序，創建一個新的庫應用程序並檢查仍然啓用了哪些與服務器應用程序相反）。