If you have used the Fluent API to configure your Code First model, you may be familiar with specifying attributes fluently instead of using Data Annotations.

Two of the Data Annotations that inherit from ValidationAttribute—MaxLength and Required—have Fluent API counterparts. This is due to the fact that MaxLength and Required are attributes that impact the model’s comprehension of the database schema and therefore impact how Entity Framework maps the classes to the database.

The Validation API will check these two rules if you configure them with the Fluent API. For example, you could replace the [MaxLength] annotation on Person.LastName with this code added into the BreakAwayContext.OnModelCreating method:

modelBuilder.Entity<Person>()
  .Property(p => p.LastName).HasMaxLength(10)

If you return to the ValidateNewPerson method from Example 6-1, ensure the LastName property is set to “Lerman-Flynn,” and then rerun the method, it will result in a message from the console application: “Person is Invalid.”

Underneath the covers, Entity Framework is using the StringLengthAttribute (or in the case of a Required scalar, the RequiredAttribute) to validate the HasMaxLength facet of Person.FirstName. Although the example only checks the IsValid property, the details of the error are returned by GetValidationResult, and you’ll see how to read these shortly.

It is possible to have properties in your class that do not map to the database. By convention, properties that do not have both a setter and a getter will not be part of the model. These are also known as transient properties. You can also configure a property to be unmapped using the NotMapped data annotation or the Ignore fluent method. By default, unmapped properties will not get validated.

However, if you have applied a ValidationAttribute to a transient property (as long as that property is in a class that is part of the model), Entity Framework will validate those rules as well.

Entity Framework’s conceptual model supports the use of complex types, also known as value objects. You can configure a complex type both in the Entity Data Model designer as well as with Code First. It is also possible (and feasible) to apply attributes to the properties of complex types. Entity Framework’s GetValidationResult will validate attributes placed on complex type properties.

It’s easy to apply data annotations to your class and then use that class with Entity Framework thanks to Code First, but what if you are using the Entity Data Model designer to create your Database First or Code First model and then relying on code generation to create your classes? There’s no opportunity to apply Data Annotations to your properties. You might modify the T4 template to apply Data Annotations that follow very common patterns in your classes, but typically this is not the appropriate mechanism for applying property-by-property attributes.

The generated classes are partial classes, which does give you the ability to add more logic to the classes with additional partial classes. However, you cannot add attributes in one partial class to properties that are declared in another partial class.

But all is not lost. There is a feature in .NET called an associated metadata class that allows you to add metadata to classes in an external file. These classes are commonly referred to as “buddy classes,” although we are more fond of the term “ugly buddy classes” because they feel a little kludgy. However ugly, they are a great way to apply data annotations to generated code. So setting aside illusions of grandeur about our code, let’s take a look at a simple example of an associated metadata class.

If you are using the DbContext Generator template to generate classes from an EDMX, the Person class will be declared as a partial class:

  public partial class Person

and the scalar properties will be simple. Here is what the FirstName property will look like:

public string FirstName { get; set; }

You can create a new class where you can mimic the property declaration and apply the attribute:

class Person_Metadata {
    [MinLength(10)]
    public string FirstName { get; set; }
}

Then you need to let the Person class know to use the Person_Metadata class for the sole purpose of reading the attributes.

You do this by applying the Metadata attribute to the Person class:

[MetadataType(typeof(Person_Metadata))]
  public partial class Person

Looking back at Figure 6-2, you’ll see that when we set the LastName to Lerman-Flynn, which exceeded the MaxLength(10) specification, the result’s ValidationErrors collection contains a single DbValidationError. DbValidationError exposes two properties, the name of the property and the actual error message.

Where did the error message come from? The internal validation logic has a formula that composes a message using the property name and the annotation that failed. This is default behavior.

You can specify your own error message in any ValidationAttribute. For example, if you were writing error messages for an application used by surfers, you might want to specify one like this:

[MaxLength(10,
           ErrorMessage= "Dude! Last name is too long! 10 is max.")]
public string LastName { get; set; }

Figure 6-3 shows the new ErrorMessage returned in a DbEntityValidationError.

Figure 6-3. ErrorMessage and PropertyName of a DbValidationError

As mentioned in the earlier note, MEF, MVC, and Dynamic Data are able to leverage the ValidationAttribute. Although the ValidateNewPerson method demonstrated using DbContext to perform the validation, it is also possible to validate ValidationAttributes directly using its Validate method. This is a great benefit for client-side development. However, since the focus of this book is DbContext, we’ll focus on how the DbContext works with the ValidationAttributes at the data layer. Remember that DbContext checks more than just ValidationAttributes, so you can benefit from these as well as other rules all at once on the server side with DbContext.

If you are calling GetValidationResults directly, you will have to write your own logic to interact with the DbEntityValidationResult, read the errors, and handle them, whether for logging or returning to the UI to present to the user.

In the case of the validation detected in ValidateNewPerson, there is a single error inside the ValidationErrors property. You could get to it by requesting that first error. For example:

var result = context.Entry(person).GetValidationResult();
if (!result.IsValid)
{
  Console.WriteLine(
    result.ValidationErrors.First().ErrorMessage);
}

That will work if you only expect or only care about the first error. However, if you have numerous ValidationAttributes defined on a type and more than one is broken, there will be more than one DbEntityValidationError in the ValidationErrors property.

What if the Person class also had a rule that the FirstName property must be at least three characters?

    [MinLength(3)]
    public string FirstName { get; set; }

If you were to update the ValidateNewPerson method from Example 6-1 to insert just the letter J as the FirstName, the validation will see two errors, as shown in Figure 6-4.

Figure 6-4. Two errors inside of the result’s ValidationErrors property

It might be wiser, therefore, to iterate through the errors. You’ll need to add a using statement for the System.Data.Entity.Validation namespace:

foreach (DbValidationError error in result.ValidationErrors)
{
  Console.WriteLine(error.ErrorMessage);
}

private static void ConsoleValidationResults(object entity)
{
  using (var context = new BreakAwayContext())
  {
    var result = context.Entry(entity).GetValidationResult();
    foreach (DbValidationError error in result.ValidationErrors)
    {
      Console.WriteLine(error.ErrorMessage);
    }
  }
}

You can build custom validation logic that can be applied to a property using a CustomValidationAttribute. These too will get checked during Entity Framework validation. Example 6-3 shows an example of a static class, BusinessValidations, which contains a single validation, DescriptionRules, to be used on various description properties in the model. The rule checks for exclamation points and a few emoticons to ensure that trip descriptions or other descriptions don’t read as though they were text messages! ☺

using System.ComponentModel.DataAnnotations;

namespace Model
{
  public static class BusinessValidations
  {
    public static ValidationResult DescriptionRules(string value)
    {
      var errors = new System.Text.StringBuilder();
      if (value != null)
      {
        var description = value as string;

        if (description.Contains("!"))
        {
          errors.AppendLine("Description should not contain '!'.");
        }
        if (description.Contains(":)") ||
             description.Contains(":("))
        {
          errors.AppendLine(
           "Description should not contain emoticons.");
        }
      }
      if (errors.Length > 0)
        return new ValidationResult(errors.ToString());
      else
        return ValidationResult.Success;
    }
  }
}

You can apply the validation to properties using the CustomValidationAttribute, as shown in Example 6-4, where we’ve added the annotation to the Destination.Description property (which already has a MaxLength annotation). The attribute requires that you specify the class where the validation method exists and then the name of the method as a string.

[MaxLength(500)]
[CustomValidation(typeof(BusinessValidations), "DescriptionRules")]
public string Description { get; set; }

If you’d like to test out the validation, you can modify the ValidateDestination method to insert some of the undesirable characters into the Description string, as we’ve done in Example 6-5.

public static void ValidateDestination()
{
  ConsoleValidationResults(
    new Destination {
      Name = "New York City",
      Country = "U.S.A",
      Description = "Big city! :) "
    });
}

Executing the method will cause the validation to return the following list of errors:

The field Country must match the regular expression '^[a-zA-Z''-'s]{1,40}$'.
Description should not contain '!'.
Description should not contain emoticons.

Both the RegularExpression validation on the Country property and the DescriptionRules custom validation on Description are reported.

In addition to the ValidationAttribute, .NET 4 introduced another feature to help developers with validation logic—the IValidatableObject interface. IValidatableObject provides a Validate method to let developers (or frameworks) provide their own context from which to perform the validation.

If an entity that is being validated implements the IValidatableObject interface, the Validation API logic will recognize this, call the Validate method, and surface the results of the validation in a DbEntityValidationError.

What does IValidatableObject provide that is not satisfied with Data Annotations? The Data Annotations let you specify a limited number of rules for individual properties. With the additional Validate method, you can provide any type of logic that can be constrained to the class. What we mean by constrained is that the validation logic won’t rely on external objects since you can’t guarantee that they’ll be available when the validation is being performed. A typical example is comparing date properties in a class.

The Trip type has StartDate and EndDate fields. Let’s use IValidatableObject to define a rule that EndDate must be greater than StartDate.

Example 6-7 shows the Trip class after we’ve added the IValidatableObject implementation that includes the Validate method. Validate compares the dates and returns a ValidationResult if the rule is broken. Notice that we’ve also added the DescriptionRules attribute we created in Example 6-3 to the Description field.

public class Trip : IValidatableObject
{
  [Key, DatabaseGenerated(DatabaseGeneratedOption.Identity)]
  public Guid Identifier { get; set; }
  public DateTime StartDate { get; set; }
  public DateTime EndDate { get; set; }
  [CustomValidation(typeof(BusinessValidations), "DescriptionRules")]
  public string Description { get; set; }
  public decimal CostUSD { get; set; }
  [Timestamp]
  public byte[] RowVersion { get; set; }

  public int DestinationId { get; set; }
  [Required]
  public Destination Destination { get; set; }
  public List<Activity> Activities { get; set; }

  public IEnumerable<ValidationResult> Validate(
    ValidationContext validationContext)
  {
    if (StartDate.Date >= EndDate.Date)
    {
      yield return new ValidationResult(
        "Start Date must be earlier than End Date",
        new[] { "StartDate", "EndDate" });
    }
  }
}

Visual Basic (VB) does not have a yield keyword. Instead, you can create a List<ValidationResult>, add each ValidationResult into that list, and then return it. Example 6-8 shows the Validate method as you would write it in VB.

Public Function Validate(
 ByVal validationContext As ValidationContext)
 As IEnumerable(Of ValidationResult)
 Implements IValidatableObject.Validate
  Dim results = New List(Of ValidationResult)
  If StartDate.Date >= EndDate.Date Then
    results.Add(New ValidationResult
                   ("Start Date must be earlier than End Date",
                    {"StartDate", "EndDate"}))
  End If
  Return result
End Function

We’ve added a new method to the console application called ValidateTrip, shown in Example 6-9.

private static void ValidateTrip()
{
  ConsoleValidationResults(new Trip
  {
    EndDate = DateTime.Now,
    StartDate = DateTime.Now.AddDays(2),
    CostUSD = 500.00M,
    Destination = new Destination { Name = "Somewhere Fun" }
  });
}

When calling ValidateTrip, the application displays the error message, “Start Date must be earlier than End Date.” But it’s listed twice. That’s because the Validate method listed this as a problem for both StartDate and EndDate, so it created two separate errors. The DbValidationError.ErrorMessage is the same in both, but one has “EndDate” in its DbValidationError.PropertyName while the other has “StartDate.”

This is important for data binding with frameworks such as MVC or WPF where you can bind the errors to the displayed properties. If we modify the ValidateTrip method to ensure that EndDate is a later date than StartDate, the ValidateTrip method returns no error messages.

You can add as many class validations as you like in your Validate method. With the C# yield keyword, all of the ValidationResult types created will be contained within the IEnumerable that’s returned by the method.

Example 6-10 shows the Trip.Validate method with a second validation added that checks against a list of words that are undesirable for describing trips. You could use a RegularExpression annotation with the word list, but this method gives you the opportunity to store the list of words in a resource file so that it’s not hard-coded into the application. The list is hard-coded into this example only for the simplicity of demonstrating the validation. You’ll need to add a using statement for the System.Linq namespace.

public IEnumerable<ValidationResult> Validate(
  ValidationContext validationContext)
{
  if (StartDate.Date >= EndDate.Date)
  {
    yield return new ValidationResult(
      "Start Date must be earlier than End Date",
      new[] { "StartDate", "EndDate" });
  }

  var unwantedWords = new List<string> 
  {
    "sad", 
    "worry", 
    "freezing", 
    "cold" 
  };

  var badwords = unwantedWords
    .Where(word => Description.Contains(word));

  if (badwords.Any())
  {
    yield return new ValidationResult(
      "Description has bad words: " + string.Join(";", badwords),
      new[] { "Description" });
  }
}

Now we’ll modify the ValidateTrip method to add a Description (which includes the undesirable words “freezing” and “worry”) to the new trip before the validation is performed (Example 6-11).

private static void ValidateTrip()
{
  ConsoleValidationResults(new Trip
   {
    EndDate = DateTime.Now,
    StartDate = DateTime.Now.AddDays(2),
    CostUSD = 500.00M,
    Description="Don't worry about freezing on this trip",
    Destination = new Destination { Name = "Somewhere Fun" }
  });
}

When running ValidateTrip with this trip that now breaks two rules, both error messages are displayed in the console window:

Start Date must be earlier than End Date
Start Date must be earlier than End Date
Description has bad words: worry;freezing

In the previous section, Validating Individual Properties on Demand, you created a method to explore the DbPropertyEntry.GetValidationErrors. Looking back at Example 6-6, notice that in addition to the emoticon in the description, there is what you now know to be an undesirable word—freezing. If you were to run the method again, the console window would still only report a single error, which is a result of the emoticon. It seems to ignore the problem with the word freezing. That’s because the validation that checks for the word freezing is defined for the class. DbPropertyEntry.GetValidationErrors can only check ValidationAttributes placed on properties.

You can also use CustomValidationAttribute on a type rather than an individual property, allowing you to define a validation that takes into account more than a single property. We’ll show you how you can define the same validation in the IValidatableObject example above by using CustomValidationAttribute.

The signature of a CustomValidationAttribute has the target type specified in the parameter along with a ValidationContext, which is used in the same way as the ValidationContext parameter of the Validate method. Example 6-12 shows two validation methods that are added into the Trip class. Notice that these methods are both public and static. Also notice that we’re using separate methods for each validation. That’s because a ValidationAttribute can only return a single ValidationResult.

public static ValidationResult TripDateValidator(
  Trip trip, 
  ValidationContext validationContext)
{
  if (trip.StartDate.Date >= trip.EndDate.Date)
  {
    return new ValidationResult(
      "Start Date must be earlier than End Date",
      new[] { "StartDate", "EndDate" });
  }

  return ValidationResult.Success;
}

public static ValidationResult TripCostInDescriptionValidator(
  Trip trip, 
  ValidationContext validationContext)
{
  if (trip.CostUSD > 0)
  {
    if (trip.Description
      .Contains(Convert.ToInt32(trip.CostUSD).ToString()))
    {
      return new ValidationResult(
        "Description cannot contain trip cost",
        new[] { "Description" });
    }
  }

  return ValidationResult.Success;
}

The first method, TripDateValidator, mimics a validation you used earlier—checking that the StartDate is earlier than the EndDate. The second method, TripCostInDescriptionValidator, checks to make sure that a user hasn’t written the trip cost into the description. The logic in that method could be fine-tuned for a production application, but it should suffice for this demonstration.

There’s a notable difference with these methods when comparing them to the Validate method you saw earlier. The Validate method has access to private methods, properties, and fields. But because of the way the ValidationAttribute is handled under the covers triggering those methods (which is also why they must be public and static), it will not have this access.

To have both validations executed, you need to add them as separate attributes on the Trip class, as shown in Example 6-13.

[CustomValidation(typeof(Trip), "TripDateValidator")]
[CustomValidation(typeof(Trip), "TripCostInDescriptionValidator")]
public class Trip: IValidatableObject

If you were to run the ValidateTrip method, the console window would display this:

Start Date must be earlier than End Date
Start Date must be earlier than End Date
Start Date must be earlier than End Date
Start Date must be earlier than End Date
Description has bad words: worry;freezing

As a reminder, because the validator creates the ValidationResult specifying that it’s for both the StartDate field and for the EndDate property, the error is listed once for each property. If you were to inspect the ValidationResult more closely, you would see that the errors are differentiated by their PropertyName. You’re also seeing the errors generated by the Validate method. The Validate method is also checking the date range as well as checking the Description for unwanted words.

Modify the ValidateTrip method to break the TripCostInDescriptionValidator rule as follows, changing the value of the Description:

private static void ValidateTrip()
{
  ConsoleValidationResults(new Trip
  {
    EndDate = DateTime.Now,
    StartDate = DateTime.Now.AddDays(2),
    CostUSD = 500.00M,
    Description = "You should enjoy this 500 dollar trip",
    Destination = new Destination { Name = "Somewhere Fun" }
  });
}

Running the application again would result in the two errors from the problem with the date properties as well as the error message from the failed TripCostInDescriptionValidator validation:

Description cannot contain trip cost
Start Date must be earlier than End Date
Start Date must be earlier than End Date
Start Date must be earlier than End Date
Start Date must be earlier than End Date

Later in this section, you’ll learn how to disable the automatic validation that occurs during SaveChanges. You may already be familiar with how ObjectContext.SaveChanges works in the Entity Framework. For a brief overview, it follows this workflow (note that this is not taking DbContext into account yet —only the internal workflow):

Because SaveChanges uses a DbTransaction by default, in either of the circumstances that causes the routine to throw an exception, any of the commands that succeeded up until that point are rolled back.

When you use DbContext to call SaveChanges, one additional step is performed prior to the first step in the ObjectContext.Savechanges workflow. DbContext.SaveChanges calls GetValidationErrors, which runs through the ValidateEntity process. If no errors are found, it then calls ObjectContext.SaveChanges. Because GetValidationErrors has already called DetectChanges, ObjectContext.SaveChanges skips its own call to DetectChanges.

Figure 6-5 shows the execution path when your code calls DbContext.SaveChanges.

Figure 6-5. Database persistence workflow beginning with DbContext.SaveChanges

What this means to you is that, by default, Entity Framework will validate all of the rules specified with ValidationAttributes and IValidatableObject automatically when you call SaveChanges from a DbContext.

If errors are detected during GetValidationErrors, SaveChanges will throw a DbEntityValidationException with the results of GetValidationErrors in its EntityValidationErrors property. In this case, the context will never make the call to ObjectContext.SaveChanges.

In the previous section, you learned that ValidationEntity, called by GetValidationErrors, will not check relationship constraints unless they are specified in configuration. However, ObjectContext.SaveChanges has always checked relationship constraints and continues to do so. Therefore, any relationship constraints that were not validated by GetValidationErrors will be checked in the next stage of the save. The same applies to null complex properties. Since null complex properties are not supported, ObjectContext always checks if a complex property is not null. Having the Required attribute on a complex property makes sense only for consistency reasons (that is, a null complex property violation will be reported the same way as other validation violations).

If you’d like to see this in action, you can modify the ValidateEverything method so that rather than explicitly calling GetValidationErrors, it will call SaveChanges. Replace the final line of the ValidateEverything method from Example 6-14 (i.e., the code line that calls into DisplayErrors) with the code in Example 6-17. You’ll call SaveChanges instead and then display information about any validation exceptions.

try
{
  context.SaveChanges();
  Console.WriteLine("Save Succeeded.");
}
catch (DbEntityValidationException ex)
{
  Console.WriteLine(
    "Validation failed for {0} objects",
    ex.EntityValidationErrors.Count());
}

Because this example contains intentional problems that will be detected during the internal call to GetValidationErrors, ObjectContext.SaveChanges will never be executed and your data will not be persisted to the database. If the validations were to pass, there’s still a chance of an UpdateException when the lower-level ObjectContext.SaveChanges is called internally, but we’re ignoring that possibility in this example.

If you were to run this method, you would find is that a DbEntityValidationException is thrown. DbEntityValidationException has a property called EntityValidationErrors which returns an IEnumerable of something you are already familiar with—EntityValidationResults that were created for each failed entity.

Figure 6-6 shows the DbValidationException in the debug window (with private fields removed for clarity).

Figure 6-6. Inspecting a DbValidationException

The exception handler in Example 6-17 displays how many EntityValidationResult instances are contained in the exception, in other words, how many entities failed validation when SaveChanges was called.

Because you already know how to iterate through EntityValidationResult objects, you can dig further into the exception if you want to relay the details of the validation errors.

You may want to exert more control over when validation occurs by calling the various validation methods explicitly in your application. You can prevent Entity Framework from triggering the validation during SaveChanges thanks to the DbContext.Configuration property. One of the settings you can configure on DbContext is ValidateOnSaveEnabled. This is set to true by an internal method when you instantiate a new DbContext, which means that it’s true by default on any DbContext class.

You can disable it in the constructor of your context class so that it’s always false whenever you instantiate a new instance of the context.

For example, in BreakAwayContext you could add the following constructor:

public class BreakAwayContext : DbContext
{
  public BreakAwayContext()
  {
    Configuration.ValidateOnSaveEnabled = false;
  }
  ... rest of class logic
}

You can also enable or disable this feature as needed throughout your application by modifying the configuration setting on your context instance.

One benefit of disabling the validation on SaveChanges and calling the validation methods explicitly is that it allows you to avoid having an exception thrown. When validations fail inside of the SaveChanges call, SaveChanges throws the DbEntityValidationException. However, as you’ve seen through this chapter, calling GetValidationResult or GetValidationErrors explicitly returns something whether the validations pass or fail. GetValidationResult returns a ValidationResult that will indicate whether or not the validation passed. GetValidationErrors returns an IEnumerable of ValidationResults for failed validations and if there were none, the IEnumerable will be empty. When application performance is an important factor in your development process, the expense of exceptions might be the deciding factor for choosing the automatic validation during SaveChanges or disabling that and taking control over how and when validation occurs. You’ll learn more about taking advantage of this configuration in the next chapter.