私たちは、SQLバックエンドを使用するレガシーVB6システムの代わりに取り組んでいます。ほとんどのビジネスロジックはストアドプロシージャとトリガにあります。現在、データベース内のトリガーを使用してキュー（SQLTransport）にメッセージを配置することにより、NServiceBusの機能をいくつか備えています。NServiceBusとREST APIを使用したアプリケーションアーキテクチャ
すべての同じテーブルとストアドプロシージャを舞台裏で使用する新しいクリーンAPIを構築したいと考えています。すべてのアプリケーションとサービスが新しいAPIやメッセージングシステムを使用すると、バックエンドをクリーンアップすることができます。
新しいフロントエンドは、データを取得するためにREST APIを呼び出します。私が苦労しているのは、データを作成/更新/削除する操作を実行するベストプラクティスです。即時応答を必要としない自動化されたプロセスの場合、バスを介してコマンドを送信するだけで済みます。ただし、アプリケーションを使用するエンドユーザーにとっては、すぐに結果が期待されます。何かによってメッセージがFLR/SLRに送られた場合、クライアントが何か起こることを期待してそこに座ることは明らかに容認できません。
1つのアイデアは、APIとNServiceBusメッセージハンドラの両方が使用できるデータベースへのすべての呼び出しを処理するライブラリを持つことです。私が見る問題は、オペレーションがイベントを公開する必要があるときです。メッセージハンドラからは、単にメッセージを公開することができます。 REST APIから単純なコマンドを処理している場合、同じイベントを公開することはできません（REST APIには何も登録されていないため、可能性があります）。
REST API送信エンドポイント（他のエンドポイントが購読しているエンドポイント）にメッセージを発行して、すべてのサブスクライバにイベントを公開します。
他のユーザーはどうやって実装していますか？は、クライアントがリアルタイムの結果を期待する簡単な作成/更新/削除操作ですが、バックエンドは何かが発生したことを示すイベントを公開する必要があります。
http://docs.particular.net/nservicebus/hosting/publishing-from-web-applications –
ありがとう、私はこれを何度か読んだことがあります。 「これらの事実を考えると、Webアプリケーションのコンテキストでは、バックエンドのサービスエンドポイントにコマンドを送信するほうが似通ったイベントを発行できるということが、従来の知恵から示唆されています。それ以外にも別のサブスクリプションマネージャエンドポイントを持つことができ、Webアプリケーションが同じサブスクリプションストレージを共有するという別のオプションがあります。 – Mark