2

ご存知かもしれませんが、マネージ コード (.NET アプリ) はEnterpriseServicesを介して COM+ を利用できます。これにより、分散トランザクションリソース プール同期などの問題を「簡単にプログラミング」できます。これは、ソリューションが COM+ によってアプリケーションをサポートするインフラストラクチャとして提供されるためです。 .

アプリケーション サーバーが Windows ドメインにある場合、COM+は「スレッド プーリング、オブジェクト プーリング、ジャスト イン タイムのオブジェクト アクティベーションを提供することで、自動的にアプリケーションのスケーラビリティを高めます。トランザクションがネットワーク上の複数のデータベースにまたがる場合" (MS ソース)

たとえば、再利用できる COM+ コンポーネントを作成していない会社で、大きなアプリケーションをゼロから構築する必要があるとします。そのため、そのテクノロジに縛られることはありません。

これは大きなシステムになりますが、時間の経過とともにさらに大きくなる可能性があります。分散トランザクションが常に行われている大規模な ERP のようなものだとしましょう。最後に、システム コアが Microsoft Windows ドメインにあるとしましょう... System.EnterpriseServices (ES) による COM+ の採用を選択します。一部のコンポーネントをサードパーティが利用できるようにする必要がありますが、これは WCF を介して行うことができます。

このテクノロジーが利用可能であり、環境に互換性があることを知っていれば、それを使用しますか?

答えが「いいえ」の場合、COM+ が提供するすべてのサービス (分散トランザクションなど) は、完全に管理された環境で利用可能で使いやすいですか?

4

2 に答える 2

1

まだ COM と結婚していない場合は、おそらく EnterpriseServices を使用しないでしょう。私は今朝、同様の問題について考えていました。COM の経験があれば、EnterpriseServices は天の恵みです。今後は、より最新の (.NET) インフラストラクチャを選択します。

  1. 開発者 (およびトレーニング) を見つけやすくなります
  2. サードパーティ ソフトウェアは .NET に重点を置く
  3. MS PSS は .NET 開発により利用可能です (COM サポートを段階的に廃止していないことは知っていますが、2 つの異なる問題を呼び出して、応答の時間を計ってください)。
于 2009-01-07T15:56:45.437 に答える
0

いいえ。

COM+ で .Net を使用したとき、問題が解決しませんでした (主に COM+ での解決できないメモリ リーク - 私たちが影響を与えることができなかったさまざまな COM+ 相互運用ビットが原因でした)。ビジネス層の機能を公開する WCFServices に変更し、分散トランザクションを最小限に抑えました (つまり、トランザクションは WCF サービス内で完了します - 実際に実行できる唯一の方法です)。組み込みの .Net Transaction スタッフを使用すると、トランザクションごとに処理するために必要なすべてが処理されます。

機能を公開するために、さまざまな WCF サービス レイヤーを使用します。内部層を 1 つ保持し、内部層と通信する外部層で公開サービスを提供します。少し重いですが、後でうまく拡張できるようで、期待する (そして必要な) セキュリティを提供します。

于 2009-02-24T23:56:25.407 に答える