6

COM +アプリケーションが作成されると、ウィザードはライブラリとサーバーアプリケーションのどちらかを選択するように提案します。

サーバーアプリケーションは別のプロセスでアクティブ化され、これを使用して、64ビットのコンシューマーと32ビットのインプロセスCOMコンポーネントを安価に相互運用できます。

呼び出し元のプロセスでアクティブ化されるライブラリアプリケーションの用途は何ですか？昔ながらのインプロセスCOMサーバーの代わりにそれらを使用するのはなぜですか？

4

2 に答える 2

3

いくつかあります：

  1. パフォーマンス - メッセージの自動化 (マーシャリングとアンマーシャリング) を行う必要がないため、少し高速です。

  2. 分離 - 多くの異なるアプリケーションがライブラリを使用している場合、それぞれに独自のコピーがあります。この点は、MTA (Multi Threaded Apartment) と STA (Single Threaded Apartment Model) の違いを扱うときに最も重要です。

IN-PROC サーバー (実際にはプロセス外、呼び出し元のプロセス外) は、すべての異なる呼び出し元によって共有されます (これは、安価な IPC/RPC を実現する優れた方法です)。

わかりました、いくつかの定義と参照を追加して編集しています。

  1. コンテキストは、実際にはオブジェクトの使用に関するすべての状態です。
  2. 因果関係は、実際には、コンテキスト内のオブジェクトの使用を示すスレッドのような概念です。(「因果関係とは、任意の数のプロセス内の任意の数のコンテキストにまたがる COM メソッド呼び出しの分散チェーンです」 - ISBN: 0-201-61594-0 より)

これらの概念については、Tim Ewald の優れた本「Transactional COM+」ISBN: 0-201-61594-0 の第 2 章の約 30 ページで説明されています。

したがって、第 2 章の要約から直接引用します。コンテキストに到達することで、COM+ 開発は従来の COM 開発とは大きく異なります。」

最後に、第 2 章では「なぜライブラリ アプリケーションを使用するのか?」という議論があります (これは、あなたの質問である単純な古い COM ではないのはなぜですか?) 彼の議論は主に、COM オブジェクトを使用することと同じ理由を示しています。実例。2. 非 DLLhost.exe プロセスにロードします。3. オーバーヘッドが大幅に削減されます。4. 共通オブジェクトの簡単なデプロイ。

したがって、要するに、分散型ではなく、本質的にトランザクション型でない場合、COM よりも COM+ を使用しても実際の利点はない可能性があるということです。しかし、COM+ アプリケーションを作成して LIBRARY アプリケーションとして展開すると、COM コンポーネントのように動作します。

それが役立つことを願っています。

于 2009-11-19T19:40:31.620 に答える
1

主な目的は、COM+ アプリケーション コンテキストを活用することです。

IObjectContextまたはのCoGetObjectContextはIObjectContextActivity、純粋なインプロセス コンポーネントから E_NOTINTERFACE を返しますが、COM+ ライブラリ アプリケーション (およびもちろんサーバー アプリケーション) では正常に動作します。

セキュリティ コンテキストは、CoGetCallContext forからも利用できますISecurityCallContext。

パフォーマンスや分離とは関係ありません。

サイト ノートとして、COM+ ライブラリ アプリケーションで利用できるものを確認する 1 つの方法は、dcomcnfg.exe を実行し、[コンポーネント サービス]、[コンピュータ]、[マイ コンピュータ]、[COM+ アプリケーション] に移動し、新しいライブラリ アプリケーションを作成して、(サーバーではなく) まだ有効になっているものを確認することです。応用）。

于 2015-06-15T08:30:26.223 に答える