FirstName、LastName、DOBの各プロパティと、Idプロパティ（プライマリキー）を持つPersonのような単純なクラスが与えられています。最初にEFコードで論理重複を防ぐ方法はありますか？
作成アクションを呼び出すと、渡すモデルがFirstName、LastName、およびDOBプロパティで既に存在するレコードと一致するかどうかを確認する検証を実行したいと考えています。この場合、Idプロパティを除外したいのは、アプリケーションに入ってくるモデルにまだモデルがなく、誤認を生成するためです。
現在、私はちょうど確かに動作しますが、完全に、よく、エレガントではありませんので...
if (!context.People.Any(x => x.FirstName == model.FirstName && x.LastName ==
model.LastName && x.DOB == model.DOB))
のような任意の拡張メソッドを使用しています。
確かに良い方法がありますか？
Anyコールをコントローラで直接表示したくない場合や、コールをまったく気に入らない場合は問題ですか？
前者の場合は、検証フレームワークを使用してコントローラから詳細を非表示にします。後者の場合は、データベースにストアド・プロシージャ/関数を作成し、代わりに呼び出すことができます。
私は本当にこのコードが悪いとは思わない。私はちょうどそれが検証である必要があると思う。 FluentValidationはこれにはかなりいいですが、DataAnnotationsも同様に機能します。
本当の問題は、Anyの呼び出しはそれぞれの場合にそれぞれの非キープロパティを書き出すことに依存するエンティティではなく、1つの汎用コールを持つ。今私はモデルを受け入れ、非キープロパティの値と一致する拡張メソッドを書くかもしれないと思っています。 結論として、私は「どうすればこれよりも怠け者になるの？」という質問をすることができました。 – keithwarren7
あなたの質問に答えようとしているのは、その拡張メソッドを書くことです。それは最善の解決策のようです。どうやって怠け者になれますか？それで頼んで、誰かがあなたのためにそれを書いてくれるかどうかを見てください;） – Sorax
@ keithwarren7 - 拡張メソッドは静的なので、拡張メソッドは悪い考えです。拡張メソッドでデータベースのクエリを実行したくないのは、プログラムの存続期間中にオープンな接続を維持するためです。 –
一意性がビジネス要件の場合は、一意の制約でデータベース内でこれを処理する必要があります。次に、あなたはチェックする必要はありません、データベースは例外をスローし、違反時にあなたに教えてくれます。例外を処理し、ユーザーがシステムにすでに存在していることをユーザーに伝えます。
私はこのアプローチに同意しません。バリデーターを使う方が良いと思います。検証に加えて固有の制約を設定することもできますが、このような例外が発生することは期待できません。しかし、私の意見。 – Dismissile
私はまた、それは非常に揮発性のソリューションです - 私は悪いコードの属性のリストでは、例外を介してアプリケーションの制御フローが本当に高いです。 – keithwarren7
@ keithwarren7 - これは制御フローではありません。例外を使用してレコードを更新したり、レコードを挿入したりすることはありません。それは悪くなるだろう。これは、ユーザーが重複レコードを挿入している場合です。あなたの唯一の選択肢は、データベースを最初に照会することですが、それをしたくないと言っています。 –
DBにユニークな制約があり、コードで適切なエラー処理が行われているようなことは避けることができます。値が保持される前に重複をチェックしたいなら、 'Any（）'は、まったくエレガントではありませんが、完全にOKです。 –
[Entity Frameworkにオブジェクトが存在するかどうかを確認する最善の方法は？]（http://stackoverflow.com/questions/1802286/best-way-to-check-if-object-exists-inentity-framework） –
これは重複していません、あなたが参照した質問の答えは、私が明示的に避けたいと言ったものです – keithwarren7