質問: 1** * 氏名:ジョン; * 電話番号:01234; 2. クライアント1は、 **この生徒**のDTOと**更新電話番号を56789**に取得し、保存アクションを許可します---> ***データベースは新しい電話の価値を56789に引き上げました。*** 3. クライアント2は、 **この生徒**のDTOと**更新フルネーム**を取得**して:Peter**に保存します---> ***データベースは新しいフルネーム:Peterと古い電話番号:01234(予期しない動作)*** **根本原因:** - 保存アクションを実行すると、クライアントは変更されたDTOをサーバーに返し、ドメインモデルにマッピングします。古い値(電話番号:01234)を保持し、この値をドメインモデルにマッピングするDTO。 --- この問題を防ぐための方法やパターン、技術を教えてください。アプリケーションが複数の人に同時に同じアプリケーションモデルを変更させる可能性があるため、この点は非常に重要です。 どうもありがとうございます
回答: それは並行性の問題と呼ばれています。それに対処する方法はたくさんあります。たとえば、SQL ServerやOracleなどのRDMS製品には、データベースベンダーのドキュメントをチェックするのに役立つ組み込みの同時処理機能が組み込まれています。最初にそれらを研究して活用し、その後あなたの好みのプログラム的アプローチを追加してください。サポートされているアプリケーションの中で以下のことが行われていることが分かりました。それぞれに問題があるため、アプリケーションに最適なものとユーザーの操作方法をテストする必要があります。 * 1つの方法は、レコードのバージョン(タイムスタンプ)を格納するフィールドを追加することです。ユーザーがレコードを保存するときは、レコードのデータベースバージョン<バージョンを確認してください。整合性を高めるために、古い値と現在の値と新しい値とを比較するチェックを追加することもできます。全てがうまくチェックされたら保存し、そうでなければ "拒否"してユーザに知らせる。 * 別の方法は、フィールドをロックフラグ(ユーザーID +タイムスタンプ)として追加することです。ユーザーがレコードの編集を要求すると、ロックフラグが更新されます(ユーザーのID +現在の時刻)。 UIでは、保存されたユーザーIDが編集モードに勝利し、他のすべてのユーザーは読み取り専用モードになります。編集ユーザーがUIから保存(または取り消し)すると、ロックフラグがクリアされ、新しい要求を編集できるようにレコードが準備されます。プロ:ユーザーはいつレコードが誰によってロックされたかを知っています。欠点:ロックを「期限切れにする」機能を追加したり、ユーザーがロックを「つかむ/盗む」機能を追加する必要があります。 * 最後に、ソリューションは、ユーザーが重複することなく事前に割り当てられたレコードセット(またはスケジュール)で作業するようにグループ化された状態で運用可能です。プリミティブですが動作します!これはユーザーの行動に依存しますが、アプリケーションの並行処理機能をまとめている間は、短期的な解決策になる可能性があります。私がサポートしているほとんどのアプリケーションでは、このアプローチの計画と実装は、とにかくユーザーのSOPになり、実際のプログラム並行性ソリューションはJICの追加の「安全性チェック」として機能します。 他にも多くの方法があり、それぞれ独自の問題があります。彼らは洗練されたシンプルにすることができます。名前付きパターンには、たとえばOCC、イベントソーシング、メッセージングなどがあります。それにもかかわらず、少なくとも1つのリクエストが「先着順」に勝つことができ、それに応じて処理される他のリクエストはすべて処理できるという前提があります。 お役に立てれば!