2

同時実行の競合をアプリケーション層に伝達する場合、コマンドクエリ分離の原則を尊重する例外を使用する代わりの方法はありますか、それとも例外は(例外をサポートする言語で)私たちが持っている最良のメカニズムですか?

私のアプリケーションの内部には、特定の高レベルのメソッドを呼び出すときに数層下で実行する楽観的ロックロジックがあります(私の場合、カスタムデータアクセス層を使用していますが、確かにオープンですORM実装がこれをどのように行うかを聞く)。アプリケーションが対話する高レベルのメソッド呼び出しは、次のようになります。

// 'data' is just a placeholder for multiple parameters, including something
// that contains row version information
void Customer.UpdateInformation(object data);

他の誰かが作業中のデータを更新したときに、Webアプリケーションのユーザーに通知できるようにする必要があります。

データを変更するメソッドから値を返したくありません。そのため、過去に例外をスローしましたが(.NETデータアダプターAPIは、競合を検出するとDBConcurrencyExceptionをスローします)、同時実行の競合は、常識的な方法では例外ではありません。それらは現実のものです。アプリケーションのワークフローの予測可能で期待される部分です。Eric Lippertの分類法では、それらは外因性の例外として適格ですか?

4

1 に答える 1

1

私の意見では、例外はこの種のエラーを伝えるための最良の方法です。プレゼンテーション層でキャッチできる特定の種類の例外をスローするため、ソリューションは非常に正しいと思います。プレゼンテーション層は、その例外の情報を使用してユーザーに表示できます。

例外が最善の方法ですが、優れたユーザーエクスペリエンスを作成することは非常に難しい場合があります。最も簡単な方法は、競合が発生したことをユーザーに通知し、変更を失うか、新しい変更を上書きするかを選択することです。競合を表示したり、オーバーライドする値とオーバーライドしない値をユーザーに選択させたりする場合は、難しくなります。または、少なくとも、これを一般的な方法で行うことは非常に困難です。競合が発生する可能性のあるシステムの画面ごとに、このような競合を解決するための特定のインターフェイスが必要になる可能性があります。

私が取り組んだシステムでは、ユーザーに表示するためのこれらの例外をほとんどキャッチできませんでした。私たちは主に、その背後にあるプロセスを変更することによって、これらの競合の発生を防止しようとしました。もちろん、それはあなたのアプリケーションの種類とビジネスがどのように機能するか(または機能するのが好きか)に完全に依存します。どのソリューションが最適か。

于 2010-06-01T15:55:00.450 に答える