Entity Framework Code First Validation

Thursday, May 9, 2013

Introduction

Most persistence frameworks implement some kind of custom validation of entities before they are sent to the database. By custom I mean something more than just “is not null”, “has XX characters”, etc. This typically includes individual properties as well as validation of the entity as a whole – for example, checking that a property’s value is valid when used together with another property’s value.

Entity Framework Code First is no exception. Out of the box it already offers a number of possibilities for validating entities that cover typical scenarios: validation by attributes or by a validation method. One validation left out is one based on XML, but since Code First doesn’t really use XML, it should be no surprise, and the other is fluent validation, something that really should be supported.

Let’s explore each of these possibilities.

Overriding ValidateEntity

The DbContext class has a virtual method called ShouldValidateEntity that is called for each entity about to be persisted – meaning, inserted or updated –, and, when it returns true – which it does by default – will trigger a call to ValidateEntity, another virtual method. In this method, we have a chance to validate our entities any way we like. An example might be, for instance, checking if the entity to be saved implements IDataErrorInfo and extract validation information from this implementation:

protected override DbEntityValidationResult ValidateEntity(DbEntityEntry entityEntry, IDictionary<Object, Object> items)

{

    DbEntityValidationResult result = base.ValidateEntity(entityEntry, items);

    IDataErrorInfo dei = entityEntry.Entity as IDataErrorInfo;

    

    foreach (String propertyName in entityEntry.CurrentValues.PropertyNames)

    {

        String errorMessage = dei[propertyName];

  

        if (String.IsNullOrWhiteSpace(errorMessage) == false)

        {

            result.ValidationErrors.Add(new DbValidationError(propertyName, errorMessage));

        }

    }

  

    return (result);

}

For the validation to occur, the ValidateOnSave property must be true, which it is by default.
Don’t forget to always call the base implementation!

Applying Validation Attributes

Another option, which also applies to ASP.NET MVC validation (see http://weblogs.asp.net/ricardoperes/archive/2012/06/03/asp-net-mvc-validation-complete.aspx) is using validation attributes, that is, attributes that inherit from ValidationAttribute. The base ValidateEntity method of DbContext also checks for these attributes, another reason why you should always call it. Let’s see an example:

[Serializable]

[AttributeUsage(AttributeTargets.Property, AllowMultiple = false, Inherited = true)]

public sealed class PositiveAttribute : ValidationAttribute

{

    protected override ValidationResult IsValid(Object value, ValidationContext validationContext)

    {

        Int64 longValue = Convert.ToInt64(value);

  

        if (longValue <= 0)

        {

            return (new ValidationResult("Value cannot be negative or zero"));

        }

  

        return (ValidationResult.Success);

    }

}

You would then apply this to some property in your entity:

public class MyEntity

{

    [Positive]

    public Int64 MyAlwaysPositiveNumber { get; set; }

}

The “problem” with this approach is that you must include any assemblies containing these custom validation attributes together with your model. If they are on the same assembly, there’s no problem.

By the way, you can specify multiple validation attributes and you can even apply them to the whole class, not just a property.

Implementing IValidatableObject

Another option, also common to MVC, is having your entities implement IValidatableObject. This interface defines a contract for returning a collection of validation errors for an entity. Here’s a sample implementation:

public class Contract : IValidatableObject

{

    public String Name { get; set; }

    public DateTime StartDate { get; set; }

    public DateTime EndDate { get; set; }

  

    public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)

    {

        if (this.StartDate >= this.EndDate)

        {

            yield return (new ValidationResult("The end date is before or the same as the start date", new String[] { "StartDate", "EndDate" }));

        }

    }

}

Handling SavingChanges Event

The “underlying” ObjectContext – which, in fact, is only created if requested – exposes a SavingChanges event which is triggered whenever Entity Framework is about to send changes to the database, typically whenever the SaveChanges method is called. If we handle this event, we can perform our custom validation before our entities are saved, and in case something is wrong we can throw an exception to cancel the saving process:

(ctx as IObjectContextAdapter).ObjectContext.SavingChanges += ObjectContext_SavingChanges;

  

void ObjectContext_SavingChanges(Object sender, EventArgs e)

{

    ObjectContext octx = sender as ObjectContext;

    IEnumerable<Object> entities = octx.ObjectStateManager.GetObjectStateEntries(EntityState.Added | EntityState.Modified).Select(x => x.Entity);

  

    //do custom validation and throw an exception if something wrong is found

  

}

This has the arguable advantage that it decouples the validation process from the entities and the context themselves.

Conclusion

In case you are using any of these validation techniques, always surround calls to SaveChanges inside a try…catch block and look out for a DbEntityValidationException or your own exception, if you followed the SavingChanges approach. Inside DbEntityValidationException you have an EntityValidationErrors that contains all the details:

try

{

    ctx.SaveChanges();

}

catch (DbEntityValidationException ex)

{

    foreach (DbEntityValidationResult result in ex.EntityValidationErrors)

    {

        //..

    }

}

Alternatively, you can explicitly call GetValidationErrors and see the collection of errors from all sources, except, of course, SavingChanges, because the context is not actually in the process of saving changes, for all entities currently being tracked by the context.

The order by which these validation processes are applied is: