私はCQRSパターンを実装しようとしていました。読み込みデータベースの更新処理は、windowsサービスを利用するのが良いですか、それとも更新データベースに新規レコードを作成する際にビューを更新するのが良いですか? トリガーまたはその他のプロセスを使用するのが最善ですか? 私はいくつかのアプローチを見てきましたが、これを達成するための最良のアプローチは何かを決めていません。
ありがとう。
私はCQRSパターンを実装しようとしていました。読み込みデータベースの更新処理は、windowsサービスを利用するのが良いですか、それとも更新データベースに新規レコードを作成する際にビューを更新するのが良いですか? トリガーまたはその他のプロセスを使用するのが最善ですか? 私はいくつかのアプローチを見てきましたが、これを達成するための最良のアプローチは何かを決めていません。
ありがとう。
個人的には、メッセージングを使用してこの種の問題を解決するのが大好きです。
コマンドは、処理時にイベントを発生させます。メッセージングを使用してイベントを公開する場合、1つ以上のダウンストリーム読み取りサービスがイベントをサブスクライブして処理し、読み取りモデルを更新できます。
この場合、メッセージングが優れている理由は、書き込み側と読み取り側を互いに分離できるためです。また、必要に応じて、複数のサブスクライバーを簡単に作成できます。さらに、MSMQのような永続的なキューイングシステムを使用したメッセージングにより、失敗したメッセージの再試行が可能になります。また、読み取りモデルをオフライン(更新など)に使用でき、モデルが復旧すると、キュー内のすべてのイベントを処理できることも意味します。
私はリレーショナルデータベースのトリガーの友達ではありませんが、テストするのはかなり難しいに違いないと思います。また、トリガーは、それが属していないルーティングロジックを導入します。トリガーアクションが失敗した場合、書き込みトランザクション全体がロールバックする可能性もありますか?トリガーはおそらく最も有益な解決策ではありません。
それは、結果整合性に関してアプリケーションがどの程度寛容でなければならないかによって異なります。
アプリで読み取りデータが 5 分経過しても問題がない場合は、書き込みデータが変更されるたびに非正規化する必要はありません。その場合、たとえば、n 分ごとに起動するバックグラウンド サービスや、CPU 消費が特定のしきい値を下回った場合にのみ起動するバックグラウンド サービスが適切なソリューションになる可能性があります。
一方、ステータスの頻繁な変更、マシンの監視、証券取引所のデータなど、アプリが時間に敏感な場合は、ラグをできるだけ低く保ち、その場で非正規化する必要があります。 -- つまり、インプロセスまたは少なくともリアルタイムです。したがって、この場合、常時実行中のプロセスでデノーマライザーを実行するか、コード内で直接イベント ハンドラーのチェーンに追加するかを選択できます。
あなたの電話。