バリデーションは、Entity Framework 4.1を紹介する上で、興味深い機能である。プロパティにアノテーションを追加することによって、エンティティをデータベースに保存する前に自動的に「オンデマンド」でバリデーションをかけることができる。バリデーションに関しては、Entity Framework 4.1のCTP5からRTWバージョンでも多くの改善が行われている。
ADO.NETチームは、バリデーションが実際にどう便利な機能なのかを説明している。
データベースに保存する前にエンティティのバリデーションを行うことは、コストがかかる操作です。アプリケーションの動作がもっさり見えるだけじゃなく、アプリケーションがSQL Azureを使っている場合、それぞれのトランザクションにかかるコストが実際にお金として必要になります。
そして
それに加えて、失敗した本当の原因を把握するのは、簡単ではありません。アプリケーション開発者は、ネストされた例外を開けて、データベースから投げられた本当の例外メッセージを取得して、アプリケーションユーザーになにが誤りかを見せることは通常しない（し、するべきではない）。理想としては、ユーザーは意味のあるエラーメッセージと、彼らがその値を修正して、データを保存することをリトライすることを容易にするためにエラーになった箇所を指すべきである。
エンティティのバリデーションは、System.ComponentModel.DataAnnotationsのValidatorを使用するのとどう違うのだろうか？
残念ながら、Validatorは、バリデーションされたオブジェクトの子プロパティに直接バリデーションを行うだけです。これは、他のバリデーションされた複雑な型にさらなる作業が必要になるということです。
幸運なことに、組み込まれたバリデーションは、上記のような問題を、コードを追加することなく解決することができます。
最初に、バリデーションはモデルのプロパティが、掘り下げるべき複雑なプロパティか、掘り下げるべきでないナビゲーションプロパティかを知っています。2番目に、あらゆるモデルやデータベースも明示しないモデルが使われています。3番目に、OnModelCreatingメソッドで作られた構成オーバーライドを尊重します。そして、あなたは、それをすべて使う必要はありません。
Entity Framework 4.1のCTP5からRTWの間に変更された内容は、以下の通り。
- データベースファーストとモデルファーストは、コードファーストに加えてサポートされている。
- MaxLengthとRequired validationは現在、スカラプロパティが対応するファセットがセットされている時に自動的に動作する。
- LazyLoadingは、バリデーションの間は無視される。
- 一時プロパティへのバリデーションが、サポートされるようになった。
- オーバーライドされたプロパティへのValidation属性が公開されるようになった。
- DetectChangesは、SaveChangesで2回呼ばれることはなくなった。
- バリデーションの例外は、DbUnexpectedValidationExceptionにラップされるようになった。
- すべての型レベルバリデーターは、1つ以上のエラーがあったとしても等しく実行される。
さらなる詳細は、ADO.NETチームのブログに書かれている。
MSDNの記事では、Entity Frameworkのバリデーションをどうやって使うかを学ぶことができるコードサンプルが提供されている。