Validation is an interesting feature introduced in Entity Framework 4.1. It enables to validate entities or their properties automatically before trying to save them to the database as well as “on demand” by using property annotations. There are also a lot of improvements made to Validation from CTP5 to RTW version of Entity Framework 4.1.
Some reasons the ADO.NET team suggests why Validation is a really useful feature -
Validating entities before trying to save changes can save trips to the database which are considered to be costly operations. Not only can they make the application look sluggish due to latency but they also can cost real money if the application is using SQL Azure where each transaction costs.
and
In addition, figuring out the real cause of the failure may not be easy. While the application developer can unwrap all the nested exceptions and get to the actual exception message thrown by the database to see what went wrong the application user will not usually be able to (and should not even be expected to be able to) do so. Ideally the user would rather see a meaningful error message and a pointer to the value that caused the failure so it is easy for him to fix the value and retry saving data.
Why this is different from using Validator from System.ComponentModel.DataAnnotations for validating the Entities?
Unfortunately Validator can validate only properties that are only direct child properties of the validated object. This means that you need to do extra work to be able to validate complex types that wouldn’t be validated otherwise.
Fortunately the built-in validation is able to solve all the above problems without having you add any additional code.
First, validation leverages the model so it knows which properties are complex properties and should be drilled into and which are navigation properties that should not be drilled into. Second, since it uses the model it is not specific for any model or database. Third, it respects configuration overrides made in OnModelCreating method. And you don’t really have to do the whole lot to use it.
There have been several changes in Validation from CTP5 to RTW version of Entity Framework 4.1, as listed below -
- Database First and Model First are now supported in addition to Code First
- MaxLength and Required validation is now performed automatically on scalar properties if the corresponding facets are set.
- LazyLoading is turned off during validation.
- Validation of transient properties is now supported.
- Validation attributes on overridden properties are now discovered.
- DetectChanges is no longer called twice in SaveChanges.
- Exceptions thrown during validation are now wrapped in a DbUnexpectedValidationException.
- All type-level validators are treated equally and all are invoked even if one or more fail.
These are explained in detail in a blog post by the ADO.NET team.
There is an article on MSDN with Code samples that can help learn more about how to use Validation with Entity Framework.