Entity Framework 4.0を使用して、一意の列制約を持つテーブルのデータにアクセスしています。制約に違反している場合、予想どおり、SaveChanges()を呼び出すと例外が発生します。私の質問は、そもそも例外がスローされることを許可する必要があるかどうかです。または、重複データの挿入を回避するために選択を行うこともできます(トランザクションが必要になると思います)。
このシナリオで一般的に受け入れられているベストプラクティスは何ですか?
Entity Framework 4.0を使用して、一意の列制約を持つテーブルのデータにアクセスしています。制約に違反している場合、予想どおり、SaveChanges()を呼び出すと例外が発生します。私の質問は、そもそも例外がスローされることを許可する必要があるかどうかです。または、重複データの挿入を回避するために選択を行うこともできます(トランザクションが必要になると思います)。
このシナリオで一般的に受け入れられているベストプラクティスは何ですか?
通常、例外を回避することは良い考えです。例外をスローすることは、かなり複雑で時間とリソースを大量に消費する操作です。したがって、一意のキー値がすでに存在するかどうかを簡単に確認できる場合は、おそらくそうします。データベースレベルでその列に一意のインデックスまたは一意の制約があるとすると、(少なくともSQL Serverの場合は)その列に既にインデックスがあるため、特定の値のチェックは非常に簡単で、パフォーマンスはそれほど高くありません。影響。
もう1つの質問は、これがどのくらいの頻度で発生すると思いますか。一日一回?数週間に一度?1分間に数回?それがかなりまれにしか起こらない場合(ブルームーンに一度)、私は最初にチェックしようとはしませんが、その場合は、例外を発生させて処理します。
それで、最初にチェックするのにどれくらいの費用がかかるか、そしてそれはどのくらいの頻度で起こるかということは本当に問題だと思いますか?とても簡単に確認できれば->ぜひチェックしてください!ただし、チェックするのがかなり複雑な操作であり、非常にまれにしか発生しない場合は、例外を処理するだけです。