1

私は現在、別の技術パートナーと協力してシス​​テムを構築するプロジェクトに取り組んでいます。システムは「監視」タイプの機能を提供し、操作は長時間実行され、多数の「イベント」が返され、処理されてユーザーに返されます。

私の最初の反応は、このすべての処理を行う Web サービスを構築し、結果をデータベースに格納して、他のテクニカル パートナーが (ある種の .NET WCF サービス インターフェイスを介して) クエリできるようにすることでした。これは、過去にこのような多くのソリューションを構築した経験が最も多い場所です。これは、データベースに何かを貼り付けて、他のプロセスがそれらにアクセスできるようにすることを介して通信が行われるという点で、ちょっと面倒に思えます。

しかし、私は最近、エンタープライズ統合パターンとメッセージング ソリューションについて多くのことを読んでおり、このソリューションにはいくつかの利点があることは確かです。これにより、イベントをキューまたはバスに配置し、それに応じて処理できます。より多くの RPC タイプの Web サービス インターフェイスよりもはるかに柔軟性が高いようです。

この種の選択をする考え/経験を持っている人はいますか? また、単一のソリューション内で混合アプローチを使用することは合理的ですか?

4

1 に答える 1

0

簡単に言えば、アプローチの必要性を駆り立てるさまざまな状況があると仮定すると、アプローチの混合は問題ないということです。

同期呼び出しが適切な場合 (おそらく Web ベースの UI でしょうか?)、Web サービスの方が「優れている」と思います。非同期の方が適切な場合は、メッセージ キューが自然な答えのように思われます。

WCF を使用すると、Web サービス、メッセージング、リモーティングなど、さまざまなバインディング タイプから選択できるため、理論上は、必要に応じて構成を介してバインディング タイプを変更することもできます。

ただし、当然のことながら、いくつかの落とし穴があります。サービスへの呼び出しは、戻り値を予期してはなりません。NetMsmqBinding は一方向通信のみをサポートします。

WCF を使用している場合、これは興味深いかもしれません: WCF Binding 決定表

于 2010-09-13T02:12:49.317 に答える