したがって、Linq-To-Sql を介してデータベースに保存されている IT/開発者チケットのリストがあります。保存の試行は、ユーザーの要求時、またはユーザーが「閉じるときに保存」と言った場合にのみ行われます。私の懸念は、ユーザーが途中で保存せずに 2 つ以上のチケットを変更することでした。
なんらかの理由で、データベースが 1 つの変更を拒否した場合、どのアイテム、またはどのチケットのどのフィールドに問題があるかについての情報があまり得られないため、ユーザーにインジケーターを提供することに結び付けることができます。彼らが編集したレコードの適切なデータを保存することができません。1 つの変更がキューに残っており、SubmitChanges が機能しなくなったためです。
すべてのチケットが別のクラスにラップされるバッファリング システムを構築して、変更が linq to sql オブジェクトに直接保存されるのではなく、バッファに保存されるようにしました。
- 新しい dataContext インスタンスを作成できます
- 個々の行の変更を保存しようとする
- 次に、失敗したそれぞれをユーザーに報告します。
私が推測しているコードにはかなりの臭いがあるか、少なくとも醜いです。
私の同僚は、私がトランザクションを試すことを提案しました. トランザクショナル アプローチをテストするために構築したものを破棄したくはありません。
- トランザクションはアイテムへのすべての変更を正しくリセットしますか、または SaveChanges が保存しようとするすべてのアイテムを正しくリセットしますか? その後、hasChanges が空で、SaveChanges が何もしないことを期待します。
- linq-to-sql で一度に個々の行の変更を送信するより良い方法はありますか?
- SaveChanges 例外で、どの行とその行のどのフィールドに問題があるかを知るのに本当に役立つ何かが欠けていますか?
おそらく、ユーザーが必要かどうかを決定するまでチケットを残すことを許可しないでください (linq-to-sql または現実の世界では、保存するかどうかを決定せずに複数のユニットを変更する機能は必要ないため)。変更を保存するかどうか。