3

データベースで読み取りおよび書き込み操作を実行し、通知を受け取るために、WCF サービスに接続するクライアントのシステムを設計する必要があります。

CQRSパターンを使用するように言われました。

例として、クライアントはサービスに接続してGet List Of ProductsやUpdate Productなどの操作を実行します。彼らはまた、出荷の受け入れや出荷の拒否などを行うこともできます(これにより、最初にそれを行うクライアントの間で競合が発生する可能性があります)。出荷を「受け入れる」または出荷を「拒否」できるクライアントは 1 人だけです。

だから私はCQRSについて少し読んで、それが（コマンドを使用して）書き込みから読み取りを分離することを理解しました。ただし、 CQRS を使用する場合、いくつかの主要な問題についてはわかりません。

  1. WCF サービスで CQRS パターンを使用する場合、データベースで同期的に行われることを期待できますか? (将来のスケーラビリティをサポートするために) サービスをシングル スレッドにしたくないので、少し混乱していますが、その一方で、サービスに対する書き込み操作が正しい順序で実行されるようにするにはどうすればよいでしょうか? または読み取り操作ですか？CQRS パターンは順序付き処理を保証しますか? （CQRSパターンは「更新」キューを使用してオフライン処理のリクエストを更新すると誰かが私に言いました）。

  2. CQRS を使用すると同時実行の問題が解消されますか?

  3. データベースと対話するすべてのコマンド ハンドラーで「TransactionScope」を引き続き使用する必要がありますか?

  4. クライアントに通知サービスを実装する方法を理解するのに 1 週​​間以上費やしましたが、うまくいきませんでした。私はこのデザインを持っています:デザイン

「製品サービス」は CQRS サービスになりますが、通知サービスに問題があります。クライアントは、製品サービスにコマンドを送信して、カテゴリ X の製品について通知を受けることができます。このコマンドは、データベース内の要求を更新します。ここでは、通知サービスが 15 分ごとにデータベースをポーリングし、どのユーザーがどのカテゴリでポーリングを希望しているかを確認し、それらの製品のカテゴリに関する通知を要求したユーザーに新製品を送信するとします。ユーザーが製品のカテゴリを変更し、他の 20 人のユーザーの通知ウィンドウにこの製品が既に表示されている場合はどうなりますか? 製品がそのカテゴリではなくなったことを検出し、次のような通知を送信する方法が必要です「あなたのビューからその製品を削除してください」。これは通知のようには聞こえません。「データベース テーブルの CONSTANT RELEVANT ビューを要求すると、すべての変更がクライアントの画面に反映されます」のように聞こえます。この種の通知サービスを行うにはどうすればよいですか??

4

2 に答える 2

2

これは特定の質問に対する回答ではないかもしれませんが、アプリケーションのどの部分で CQRS を使用できるか (または使用すべきか) を評価するのに役立つかもしれません。

より具体的には、CQRS は何があっても適用すべき特効薬でもなければ、アプリケーション全体にわたる包括的なアーキテクチャ スタイルでもありません。

CQRS を単一の適切に指定された境界付きコンテキストに適用すると、多くの利点が得られます (Eric Evans による Domain Driven Design を参照)。

あなたまたはあなたのチームが最初に尋ねるべき質問:

  • アプリケーションの境界コンテキストとは何ですか?
  • 各 BC について: 基本的に CRUD ですか、それともより複雑で洗練されたモデリングが必要ですか?
  • CRUDの場合は、そのように実装します
  • 複雑な場合、問題はすでに解決されていますか? 車輪を再発明する必要があるか、それとも完成したソリューション (概念上またはソフトウェアの一部) をそのまま使用できるか
  • 独自に構築する必要がある場合、この特定の BC は主要なビジネス価値を提供するか、実装はたとえば競争上の優位性をもたらす可能性を提供するか? (ドメイン駆動設計の「コア ドメイン」を参照)
  • 上記が当てはまる場合は、さまざまなアーキテクチャ スタイルを調査し、最適なものを選択してください。

簡単に言うと、アプリケーション全体にスタイルを強制しようとしないでください。BC を特定し、要件を満たす最も単純なソリューションをそれぞれに使用します。これは CQRS である可能性が非常に高くなりますが、アプリケーション内の最大で 1 つまたは 2 つの BC に対してです。

アプリケーションの最も複雑な部分に労力を集中し、CQRS を使用して形式化および実装した場合に真の利点を提供します。

于 2012-04-28T07:14:35.860 に答える
0
  1. データベースは同期的に処理を行うのではなく、データベース トランザクション分離レベルのルールに従ってインターリーブされるトランザクションを使用します。しかし、彼らはトランザクションの一部としてインデックスを更新します。それが重要な部分です。
  2. いいえ、そうではありませんが、データベーステーブルなどのリソースの競合が激しい場合に、単一のライターが複数のリーダーをブロックするという問題が解消されます。たとえば、私が取り組んだシステムでは、爆発データがセンサーから挿入され、ユーザー向けのレポート作成の一部として読み取られていました。これは、CQRS が適切に適合する場所です。CQRS のほとんどの実装では、同時実行の問題が制御されています。実際には、同時実行が激しく競合するビジネス ロジックである DDD と組み合わせた優れたモデルです。ただし、スタックがない、冪等性とメッセージの並べ替えで死ななければならないなど、他のプロパティが得られます。
  3. 2 つのデータベースがあります。イベント（イベントソーシングを行っている場合）/エンティティを保存するものと、イベントを最新に保ちたいビューごとに別の/複数のもの。
  4. MassTransit + SignalR のようなものを使用したいと思うでしょう。イベントをサブスクライブし、SignalR ハブを介してブラウザーに通知をプッシュする読み取りモデル (基本的には画面ごとの DTO ) を作成します。
于 2012-05-03T15:57:45.987 に答える