私は新しいプロジェクトを開始し、バックエンドでサービスを接続するためのサービスバスの概念に夢中になりました。これまでは主にWeb開発を行っていたので、ESBを介してWeb層をサービスに接続するだけでした。
今、私はサーバー/クライアント接続を必要とするデスクトップアプリケーションから始めています。ESBはデフォルトで非同期モデルを強制し、負荷を分散する際にある程度の柔軟性を可能にするため、良いアイデアのようです。また、多くの場合、Pub/Subは非常に理にかなっています。
インターネットでESBをよく読んでいますが、Ayendeは、要求/応答シナリオでESBを使用するAlexandriaアプリも作成しました。次に、ESBを介して要求/応答を行うことは悪いことだと言う人もいます。
サーバー/クライアント通信をサポートするESBで発生する可能性のある大きな問題は何ですか？
これは私にとって非常に興味深い質問です。なぜなら、私は反対の観点から同じ質問をしたからです。つまり、WinFormsからWebに（ただし、SOではなくYahooグループで）来たのです。
WinFormsでの非同期要求/応答は、箱から出してすぐにうまく機能しました。UIはクエリコマンドを起動するだけで、それを忘れます。（クエリ結果を含む）応答がたまたま入って来て、それを必要とするビューがまだ利用可能である場合、データはビューに移入されます。
私はクエリにESBを使用することが「悪い」理由のビューを形成しようとしていますが、私が思いつくことができる最善のことは、非同期モデルがページを構築するための要件に簡単に適合しないことです。 Webアプリ。また、他のより直接的なクエリメソッドよりもパフォーマンスが少し低下します。
「理由だけで」という答えは好きではないので、あなたの質問に対する他の回答に興味を持って楽しみにしています。
CQRS（コマンド/クエリ分離）に関するUdiDahanの投稿を見てください。これにより、行う必要のある決定ポイントが示されます。クライアントアプリの主な課題は、バックグラウンドでメッセージポンプを作成し、そのデータをUIスレッドにマーシャリングすることです。Webの場合、クエリをより非正規化されたストアに分離することはうまくいきましたが、この方法では、UIの構築方法について少し違った考え方をすることになります。データを取得するためにオブジェクトを47回マップする必要がないため、モデルが大幅に簡素化されます。これは、私が常に正当化するのに苦労してきました。明らかに欠点は可動部分が多いことですが、それは価値があることがわかりました。