Let’s look at how you can work with DbPropertyValues when you have a property on your entity that uses a complex type. Remember that complex types allow you to group multiple scalar values into a class. A property that references a complex type is known as a complex property. For example, the BAGA model uses an Address complex type to group address related properties (Example 5-7).

[ComplexType]
public class Address
{
  public int AddressId { get; set; }
  [MaxLength(150)]
  [Column("StreetAddress")]
  public string StreetAddress { get; set; }
  [Column("City")]
  public string City { get; set; }
  [Column("State")]
  public string State { get; set; }
  [Column("ZipCode")]
  public string ZipCode { get; set; }
}

This complex type is then used by the Address property in the Person class (Example 5-8). Person.Address is therefore a complex property. Note that PersonInfo is also a complex type.

[Table("People")]
public class Person
{
  public Person()
  {
    Address = new Address();
    Info = new PersonalInfo
    {
      Weight = new Measurement(),
      Height = new Measurement()
    };
  }

  public int PersonId { get; set; }
  [ConcurrencyCheck]
  public int SocialSecurityNumber { get; set; }
  public string FirstName { get; set; }
  public string LastName { get; set; }
  public Address Address { get; set; }
  public PersonalInfo Info { get; set; }

  public List<Lodging> PrimaryContactFor { get; set; }
  public List<Lodging> SecondaryContactFor { get; set; }
  [Required]
  public PersonPhoto Photo { get; set; }
  public List<Reservation> Reservations { get; set; }
}

To demonstrate how DbPropertyValues handles complex types, let’s create a new Person and pass it to our PrintChangeTrackingInfo method. Add the PrintPersonInfo method shown in Example 5-9.

private static void PrintPersonInfo()
{
  using (var context = new BreakAwayContext())
  {
    var person = new Person
    {
      FirstName = "John",
      LastName = "Doe",
      Address = new Address { State = "VT" }
    };

    context.People.Add(person);

    PrintChangeTrackingInfo(context, person);
  }
}

When we get the value for a complex property from DbPropertyValues, it’s going to return another DbPropertyValues that contains the values from the complex type. Let’s update the PrintPropertyValues helper method to account for this (Example 5-10).

private static void PrintPropertyValues(
  DbPropertyValues values,
  int indent = 1)
{
  foreach (var propertyName in values.PropertyNames)
  {
    var value = values[propertyName];
    if (value is DbPropertyValues)
    {
      Console.WriteLine(
        "{0}- Complex Property: {1}",
        string.Empty.PadLeft(indent),
        propertyName);

      PrintPropertyValues(
        (DbPropertyValues)value,
        indent + 1);
    }
    else
    {
      Console.WriteLine(
        "{0}- {1}: {2}",
        string.Empty.PadLeft(indent),
        propertyName,
        values[propertyName]);
    }
  }
}

For each property being printed, the code now checks if the value is a DbPropertyValues. If it is, the code prints out the name of the complex property and then recursively calls PrintPropertyValues with the values for the complex type. PrintPropertyValues also allows an indent level to be supplied, which is used to indent the values of a complex property. If an indent is not supplied, a default indent of 1 is used. Update the Main method to call PrintPersonInfo and run the application. The console will display the following output:

Type: Model.Person
State: Added

Current Values:
  - PersonId: 0
  - SocialSecurityNumber: 0
  - FirstName: John
  - LastName: Doe
  - Complex Property: Address
   - AddressId: 0
   - StreetAddress:
   - City:
   - State: VT
   - ZipCode:
  - Complex Property: Info
   - Complex Property: Weight
    - Reading: 0
    - Units:
   - Complex Property: Height
    - Reading: 0
    - Units:
    - DietryRestrictions:

The console output is displaying the property values contained in the Address property. You’ll also notice that the code works for nested complex types. Person.Info is a complex property that references the PersonInfo complex type. PersonInfo also has complex properties for a Person’s Height and Weight. From the printout you can see that the DbPropertyValues for the Info complex property returned another DbPropertyValues for its Weight and Height properties.

Having a single object, like DbPropertyValues, that represents a set of values is handy. However, we usually want to write application logic in terms of our domain classes, rather than a type such as DbPropertyValues. For example, we might have a method that defines how we display a Destination for the user of our application to see. We can pass any instance of a Destination into the method to print out its current values, but it would be good if we could use that same method to print out the original and database values as well. Add the PrintDestination method shown in Example 5-11.

private static void PrintDestination(Destination destination)
{
  Console.WriteLine("-- {0}, {1} --",
    destination.Name,
    destination.Country);

  Console.WriteLine(destination.Description);

  if (destination.TravelWarnings != null)
  {
    Console.WriteLine("WARNINGS!: {0}", destination.TravelWarnings);
  }
}

If you want to display the current values for a Destination, you can pass the actual instance to the method. But there may be scenarios where you want to display the original values fetched from the database or perhaps the current database values to the end user. One such scenario is resolving concurrency conflicts during a save. We’ll look at that particular scenario in more detail later in this chapter.

DbPropertyValues includes a ToObject method that will copy the values into a new instance of the entity without overwriting the existing instance as you would with a query to the database. To see how this works, add the TestPrintDestination method shown in Example 5-12.

private static void TestPrintDestination()
{
  using (var context = new BreakAwayContext())
  {
    var reef = (from d in context.Destinations
                where d.Name == "Great Barrier Reef"
                select d).Single();

    reef.TravelWarnings = "Watch out for sharks!";

    Console.WriteLine("Current Values");
    PrintDestination(reef);

    Console.WriteLine("
Database Values");
    DbPropertyValues dbValues = context.Entry(reef)
      .GetDatabaseValues();

    PrintDestination((Destination)dbValues.ToObject());
  }
}

The code retrieves the Great Barrier Reef Destination from the database and changes its TravelWarnings property. Then it passes the Destination to the PrintDestination method to print out the current values. Next, it gets the values from the database and uses ToObject to construct a Destination that contains the values from the database. This new Destination is then passed to PrintDestination to print the database values. Update the Main method to call TestPrintDestination and run the application:

Current Values
-- Great Barrier Reef, Australia --
Beautiful coral reef.
WARNINGS!: Watch out for sharks!

Database Values
-- Great Barrier Reef, Australia --
Beautiful coral reef

The current and database values are printed to the screen and you can see that the updated TravelWarnings property is printed out in the current values. The second instance of Destination, which was created by calling ToObject, is not attached to the context. Any changes to this second instance will not be persisted during SaveChanges.

DbPropertyValues isn’t a read-only type. You can also use it to update values that are stored in an instance. When you set values using CurrentValues or OriginalValues, this will also update the current and original values in the change tracker. Additionally, updating the CurrentValues will change the values that are stored in the properties of your entity instance.

In Recording Original Values, you saw how the OriginalValues could be individually updated. As each value was updated, the Change Tracker worked out which properties had been modified. Let’s take a look at setting the current values. Add the ChangeCurrentValue method shown in Example 5-13.

private static void ChangeCurrentValue()
{
  using (var context = new BreakAwayContext())
  {
    var hotel = (from d in context.Lodgings
                 where d.Name == "Grand Hotel"
                 select d).Single();

    context.Entry(hotel)
      .CurrentValues["Name"] = "Hotel Pretentious";

    Console.WriteLine("Property Value: {0}", hotel.Name);
  }
}

The code loads the Grand Hotel Lodging from the database. The code then gets the CurrentValues for the hotel instance and modifies the value stored for the Name property. Finally, the code writes out the value stored in the Name property on the entity. Update the Main method to call ChangeCurrentValue and run the application, which will result in the following output:

Property Value: Hotel Pretentious

We see from the output that updating the value of a property in the CurrentValues has also updated the value stored in the property of the entity.

Back in Working with Change Tracking, you learned that POCO entities require a call to DetectChanges to scan for changes in the properties of the entity. You also learned that DbContext takes care of calling DetectChanges for you, but that you can disable this behavior if you want to control when DetectChanges is called.

If you make changes using the Change Tracker API, there is no need for DetectChanges to be called, because the Change Tracker is aware of the change being made. To see this in action, update the ChangeCurrentValue method, as shown in Example 5-14.

private static void ChangeCurrentValue()
{
  using (var context = new BreakAwayContext())
  {
    context.Configuration.AutoDetectChangesEnabled = false;

    var hotel = (from d in context.Lodgings
                 where d.Name == "Grand Hotel"
                 select d).Single();

    context.Entry(hotel)
      .CurrentValues["Name"] = "Hotel Pretentious";

    Console.WriteLine("Property Value: {0}", hotel.Name);
    Console.WriteLine("State: {0}", context.Entry(hotel).State);
  }
}

The updated code now disables automatic calling of DetectChanges. The code also prints out the state of the hotel entity, as recorded by the Change Tracker, after the current value for Name has been updated. Go ahead and run the application again:

Property Value: Hotel Pretentious
State: Modified

If we had updated the Name property on the entity, we would expect the state to be Unchanged, since a call to DetectChanges would be required to discover the updated property. However, because the Name property was updated using the Change Tracker API, the state is correctly recorded as Modified without calling DetectChanges.

There may be times when you want to have an editable copy of the current or original values but you don’t want changes to be recorded in the Change Tracker. You’ll see one such scenario when we look at resolving concurrency conflicts later in this chapter. The Clone method will return a copy of any DbPropertyValues instance. Be aware that when you clone current or original values, the resulting copy will not be hooked up to the change tracker. Add the CloneCurrentValues method shown in Example 5-15 to see how cloning works.

private static void CloneCurrentValues()
{
  using (var context = new BreakAwayContext())
  {
    var hotel = (from d in context.Lodgings
                  where d.Name == "Grand Hotel"
                  select d).Single();

    var values = context.Entry(hotel).CurrentValues.Clone();

    values["Name"] = "Simple Hotel";

    Console.WriteLine("Property Value: {0}", hotel.Name);
    Console.WriteLine("State: {0}", context.Entry(hotel).State);
  }
}

The code loads the Grand Hotel Lodging from the database and then clones its current values. The value stored for the Name property in the cloned values is updated, and then the value of the Name property in the entity is written out. Update the Main method to call CloneCurrentValues and run the application to see the following output in the console:

Property Value: Grand Hotel
State: Unchanged

As expected, updating the cloned values has no impact on the values or the state of the entity they were cloned from.

private static void UndoEdits()
{
  using (var context = new BreakAwayContext())
  {
    var canyon = (from d in context.Destinations
                  where d.Name == "Grand Canyon"
                  select d).Single();

    canyon.Name = "Bigger & Better Canyon";

    var entry = context.Entry(canyon);
    entry.CurrentValues.SetValues(entry.OriginalValues);
    entry.State = EntityState.Unchanged;

    Console.WriteLine("Name: {0}", canyon.Name);
  }
}

Name: Grand Canyon

private static void CreateDavesCampsite()
{
  using (var context = new BreakAwayContext())
  {
    var davesDump = (from d in context.Lodgings
                      where d.Name == "Dave's Dump"
                      select d).Single();

    var clone = new Lodging();
    context.Lodgings.Add(clone);
    context.Entry(clone)
      .CurrentValues
      .SetValues(davesDump);

    clone.Name = "Dave's Camp";
    context.SaveChanges();

    Console.WriteLine("Name: {0}",
      clone.Name);

    Console.WriteLine("Miles: {0}",
      clone.MilesFromNearestAirport);

    Console.WriteLine("Contact Id: {0}",
      clone.PrimaryContactId);
  }
}

Name: Dave's Camp
Miles: 32.65
Contact Id: 1

Let’s start with the Property method. The Property method allows you to read and write the original and current value. It also lets you know whether an individual property is marked as Modified, something that isn’t possible with DbPropertyValues. The WorkingWithPropertyMethod method shown in Example 5-18 will allow you to begin exploring the Property method.

private static void WorkingWithPropertyMethod()
{
  using (var context = new BreakAwayContext())
  {
    var davesDump = (from d in context.Lodgings
                      where d.Name == "Dave's Dump"
                      select d).Single();

    var entry = context.Entry(davesDump);

    entry.Property(d => d.Name).CurrentValue =
      "Dave's Bargain Bungalows";

    Console.WriteLine(
      "Current Value: {0}",
      entry.Property(d => d.Name).CurrentValue);

    Console.WriteLine(
      "Original Value: {0}",
      entry.Property(d => d.Name).OriginalValue);

    Console.WriteLine(
      "Modified?: {0}",
      entry.Property(d => d.Name).IsModified);
  }
}

The code retrieves Dave’s Dump from the database and locates the representative entry from the context. It then uses the Property method to change the current value for the Name property. Then the code prints out the current and original values plus the IsModified flag. The IsModified flag tells us if the property is marked as Modified and will be updated when SaveChanges is called. You can update the Main method to call WorkingWithPropertyMethod and run the application to see these results in the console:

Current Value: Dave's Bargain Bungalows
Original Value: Dave's Dump
Modified?: True

The current and original values are displayed as expected, since we changed the value of the Name property. You can see that the property is also marked as modified. There is also a weakly typed overload of Property that accepts a string property name rather than a lambda expression. In fact, all the methods you will see in this section have a string-based overload.

The strongly typed lambda overloads are recommended because they give you a compile-time check, but the string-based overloads can be useful when writing generalized code. For example, you might want to find out which properties are currently marked as Modified. You can get the names of all properties using CurrentValues and then check if they are modified using the Property method. The FindModifiedProperties method shown in Example 5-19 demonstrates this.

private static void FindModifiedProperties()
{
  using (var context = new BreakAwayContext())
  {
    var canyon = (from d in context.Destinations
                  where d.Name == "Grand Canyon"
                  select d).Single();

    canyon.Name = "Super-Size Canyon";
    canyon.TravelWarnings = "Bigger than your brain can handle!!!";

    var entry = context.Entry(canyon);
    var propertyNames = entry.CurrentValues.PropertyNames;


IEnumerable<string> modifiedProperties = from name in propertyNames
                             where entry.Property(name).IsModified
                             select name;

    foreach (var propertyName in modifiedProperties)
    {
      Console.WriteLine(propertyName);
    }
  }
}

The code retrieves the Grand Canyon Destination from the database and changes a couple of properties. The code then locates the entry for the Grand Canyon and gets a list of all property names using CurrentValues. Then a LINQ query is used to find which of those property names are marked as modified. The where section of the LINQ query uses the string-based overload of Property to get the change tracking information for the property. Finally, the modified properties are written out to the console. When you run FindModifiedProperties, the names of the two edited properties are written out to the console:

Name
TravelWarnings

The Property method also gives you access to the name of the property and the change tracker entry for the entity containing the property. This information is provided in the Name and EntityEntry properties (Figure 5-1).

Figure 5-1. EntityEntry and Name for the TravelWarnings property

In the code you’ve seen so far, we’ve always known this information because we started with the change tracking entry and then the property name to find the information for a property. In Chapters 6 and 7 you will see how the Name and EntityEntry properties are useful in Validation scenarios.

When working with complex properties, you use the ComplexProperty method to get access to change tracking information and operations. The same operations that you just learned about for scalar properties are all available for complex properties. You can also use the Property method to drill into individual scalar properties on the complex type. The WorkingWithComplexMethod shown in Example 5-20 demonstrates interacting with the properties of the Address complex property in a Person instance.

private static void WorkingWithComplexMethod()
{
  using (var context = new BreakAwayContext())
  {
    var julie = (from p in context.People
                  where p.FirstName == "Julie"
                  select p).Single();

    var entry = context.Entry(julie);

    entry.ComplexProperty(p => p.Address)
      .Property(a => a.State)
      .CurrentValue = "VT";

    Console.WriteLine(
      "Address.State Modified?: {0}",
      entry.ComplexProperty(p => p.Address)
        .Property(a => a.State)
        .IsModified);

    Console.WriteLine(
      "Address Modified?: {0}",
      entry.ComplexProperty(p => p.Address).IsModified);

    Console.WriteLine(
      "Info.Height.Units Modified?: {0}",
      entry.ComplexProperty(p => p.Info)
        .ComplexProperty(i => i.Height)
        .Property(h => h.Units)
        .IsModified);
  }
}

The code loads data for Julie from the database and locates the change tracking entry from the context. Next it drills into the Address complex property and then into the scalar State property within Address. The code changes the current value assigned to Address.State and then prints out the IsModified flag for Address.State and for the complex Address property. Finally, the code drills into a nested complex property to check the IsModified flag for Info.Height.Units. You can see that ComplexProperty calls can be chained together to drill into a complex property that is defined in another complex property. Following are the console results after running the WorkingWithComplexMethod:

Address.State Modified?: True
Address Modified?: True
Info.Height.Units Modified?: False

An alternative syntax to access the change tracking information for a complex property is to specify the full path to the property in a single Property call. For example, you could also change the current value of Address.State using the following code:

entry.Property(p => p.Address.State).CurrentValue = "VT";

You can also specify the full path if you are using the string-based overload of Property:

entry.Property("Address.State").CurrentValue = "VT";

When working with complex properties, Entity Framework tracks that state for the complex type, but not for its individual properties. If you check the state of any property within the complex type (for example, the City property of Address), Entity Framework will return the state of the complex type (Address). After changing the Address.State property, every property of Address will be marked as modified.

So far in this section, we have always modified the scalar values of an existing complex type instance. You can also assign a new complex type instance to a complex property. In Example 5-20, instead of editing the State property of the existing Address instance, we could have replaced it with a new instance:

entry.ComplexProperty(p => p.Address)
  .CurrentValue = new Address { State = "VT" };

Replacing the value assigned to a complex property with a new instance will mark the entire complex property as modified.

Now it’s time to look at how to access the change tracking information and operations associated with a navigation property. Instead of the Property method, you use the Reference and Collection methods to get to navigation properties:

These methods give you the ability to do several things:

In Explicit Loading, you saw how the Load method can be used to load the contents of a navigation property from the database. You also learned that the IsLoaded flag can be used to determine if the entire contents of a navigation property (for example, Destination.Trips) have already been loaded. In Chapter 2 you also saw how to use the Query method to run a LINQ query against the contents of the navigation property. This was in Querying Contents of a Collection Navigation Property.

private static void WorkingWithReferenceMethod()
{
  using (var context = new BreakAwayContext())
  {
    var davesDump = (from d in context.Lodgings
                      where d.Name == "Dave's Dump"
                      select d).Single();

    var entry = context.Entry(davesDump);

    entry.Reference(l => l.Destination)
      .Load();

    var canyon = davesDump.Destination;

    Console.WriteLine(
      "Current Value After Load: {0}",
      entry.Reference(d => d.Destination)
        .CurrentValue
        .Name);

    var reef = (from d in context.Destinations
                where d.Name == "Great Barrier Reef"
                select d).Single();

    entry.Reference(d => d.Destination)
      .CurrentValue = reef;

    Console.WriteLine(
      "Current Value After Change: {0}",
      davesDump.Destination.Name);
  }
}

Current Value After Load: Grand Canyon
Current Value After Change: Great Barrier Reef

context.Configuration.AutoDetectChangesEnabled = false;
context.Configuration.LazyLoadingEnabled = false;

Console.WriteLine(
  "State: {0}",
  entry.State);

Console.WriteLine(
  "Referenced From Current Destination: {0}",
  reef.Lodgings.Contains(davesDump));

Console.WriteLine(
  "Referenced From Former Destination: {0}",
  canyon.Lodgings.Contains(davesDump));

After Load: Grand Canyon
After CurrentValue Change: Great Barrier Reef
State: Modified
Referenced From Current Destination: True
Referenced From Former Destination: False

private static void WorkingWithCollectionMethod()
{
  using (var context = new BreakAwayContext())
  {
    var res = (from r in context.Reservations
               where r.Trip.Description == "Trip from the database"
               select r).Single();

    var entry = context.Entry(res);

    entry.Collection(r => r.Payments)
      .Load();

    Console.WriteLine(
      "Payments Before Add: {0}",
      entry.Collection(r => r.Payments).CurrentValue.Count);

    var payment = new Payment { Amount = 245 };
    context.Payments.Add(payment);

    entry.Collection(r => r.Payments)
      .CurrentValue
      .Add(payment);

    Console.WriteLine(
      "Payments After Add: {0}",
      entry.Collection(r => r.Payments).CurrentValue.Count);
  }
}

Payments Before Add: 1
Payments After Add: 2

context.Configuration.AutoDetectChangesEnabled = false;

Console.WriteLine(
  "Foreign Key Before DetectChanges: {0}",
  payment.ReservationId);

context.ChangeTracker.DetectChanges();

Console.WriteLine(
  "Foreign Key After DetectChanges: {0}",
  payment.ReservationId);

Count Before Add: 1
Count After Add: 2
Foreign Key Before DetectChanges: 0
Foreign Key After DetectChanges: 1

A concurrency conflict occurs when you attempt to update a record in the database but another user has updated that same record since you queried for it. By default, Entity Framework will always update the properties that you have modified regardless of whether or not there is a concurrency conflict. However, you can configure your model so that Entity Framework will throw an exception when a concurrency conflict occurs. You do this by specifying that a specific property should be used as a concurrency token.

During SaveChanges Entity Framework will check if the value in the corresponding database column has been updated since the record was bought into memory. A concurrency exception is thrown if the value in the database has changed.

The BAGA model includes two examples of concurrency tokens. The SocialSecurityNumber property on Person is marked with the ConcurrencyCheck attribute. When updating an existing Person, Entity Framework will check that the SSN allocated to the Person when the record was retrieved from the database remains the same in the database. If another user has changed the SSN, SaveChanges will fail and a DbUpdateConcurrencyException will be thrown. The Trip class includes a RowVersion property that is marked with the Timestamp attribute. Timestamp properties are treated the same as other concurrency check properties, except the database will automatically generate a new value for this property whenever any column in the record is updated. This means that when saving changes to an existing Trip, a concurrency exception will be thrown if another user has updated any properties since the Trip was retrieved from the database.

Let’s write a method that will cause a DbUpdateConcurrencyException to be thrown when trying to save a change to an existing Trip. When the exception is thrown, we’ll ask the end user of our application to tell us how they want to resolve the conflict. Go ahead and add the ConcurrencyDemo method shown in Example 5-25.

private static void ConcurrencyDemo()
{
  using (var context = new BreakAwayContext())
  {
    var trip = (from t in context.Trips.Include(t => t.Destination)
                where t.Description == "Trip from the database"
                select t).Single();

    trip.Description = "Getaway in Vermont";

    context.Database.ExecuteSqlCommand(
      @"UPDATE dbo.Trips
        SET CostUSD = 400
        WHERE Description = 'Trip from the database'");


    SaveWithConcurrencyResolution(context);
  }
}

private static void SaveWithConcurrencyResolution(
  BreakAwayContext context)
{
  try
  {
    context.SaveChanges();
  }
  catch (DbUpdateConcurrencyException ex)
  {
    ResolveConcurrencyConflicts(ex);
    SaveWithConcurrencyResolution(context);
  }
}

The example retrieves an existing Trip from the database and changes its Description property. It then issues a raw SQL query to update the CostUSD column of the same Trip in the database. Executing this statement will cause the database to generate a new value for the RowVersion column in the database. Issuing a raw SQL statement is not a recommended practice and is just used to simulate another user changing data. Next, the code calls the SaveWithConcurrencyResolution helper method. This helper method calls SaveChanges, which will issue an UPDATE command to apply our changes to the Trip. As part of the update process, Entity Framework will check if the RowVersion column in the database still has the same value as it did when we queried for the Trip. Because of change we made with ExecuteSqlCommand, the RowVersion will have changed and a DbUpdateConcurrencyException will be thrown. The example code catches this exception and attempts to resolve the conflict with a custom method, ResolveConcurrencyConflict. Once the conflict is resolved, the code makes a recursive call to SaveWithConcurrencyResolution. The recursive call is used to ensure that we handle any further concurrency conflicts that occur after the first conflict is resolved. Example 5-26 shows the ResolveConcurrencyConflict method.

private static void ResolveConcurrencyConflicts(
  DbUpdateConcurrencyException ex)
{
  foreach (var entry in ex.Entries)
  {
    Console.WriteLine(
      "Concurrency conflict found for {0}",
      entry.Entity.GetType());

    Console.WriteLine("
You are trying to save the following values:");
    PrintPropertyValues(entry.CurrentValues);

    Console.WriteLine("
The values before you started editing were:");
    PrintPropertyValues(entry.OriginalValues);

    var databaseValues = entry.GetDatabaseValues();
    Console.WriteLine("
Another user has saved the following values:");
    PrintPropertyValues(databaseValues);

    Console.Write(
      "[S]ave your values, [D]iscard you changes or [M]erge?");

    var action = Console.ReadKey().KeyChar.ToString().ToUpper();
    switch (action)
    {
      case "S":
        entry.OriginalValues.SetValues(databaseValues);
        break;

      case "D":
        entry.Reload();
        break;

      case "M":
        var mergedValues = MergeValues(
          entry.OriginalValues,
          entry.CurrentValues,
          databaseValues);

        entry.OriginalValues.SetValues(databaseValues);
        entry.CurrentValues.SetValues(mergedValues);
        break;

      default:
        throw new ArgumentException("Invalid option");
    }
  }
}

Fortunately, the DbUpdateConcurrencyException gives you access to everything you need to know about the conflict. The exception’s Entries property gives you the DbEntityEntry for each of the entities that had a concurrency conflict.

The ResolveConcurrencyConflicts method iterates through each of the entries in the exception to resolve the conflict. It lets the user know what type of entity the conflict occurred in by checking the type of the entity in the Entity property. Next the user is shown the current, original, and database values using the PrintPropertyValues method you added back in Example 5-10. The code then gives the user three options for resolving the conflict:

The final piece of code to add is the MergeValues method that will be used when the user decides to merge his or her changes with the changes another user has applied (Example 5-27).

private static DbPropertyValues MergeValues(
  DbPropertyValues original,
  DbPropertyValues current,
  DbPropertyValues database)
{
  var result = original.Clone();

  foreach (var propertyName in original.PropertyNames)
  {
    if (original[propertyName] is DbPropertyValues)
    {
      var mergedComplexValues = MergeValues(
        (DbPropertyValues)original[propertyName],
        (DbPropertyValues)current[propertyName],
        (DbPropertyValues)database[propertyName]);

      ((DbPropertyValues)result[propertyName])
        .SetValues(mergedComplexValues);
    }
    else
    {
      if (!object.Equals(
        current[propertyName],
        original[propertyName]))
      {
        result[propertyName] = current[propertyName];
      }
      else if (!object.Equals(
        database[propertyName],
        original[propertyName]))
      {
        result[propertyName] = database[propertyName];
      }
    }
  }

  return result;
}

MergeValues begins by using the Clone method to create a set of values that will store the merged result. We are cloning from the original values, but you could clone from any of the three sets of values (current, original, or database). Note that the code is going to assume that the three sets of supplied values contain exactly the same properties—in our case, we know this is true because they come from the same entity. The method then loops through each property to perform the merge.

If the property value is a DbPropertyValues, we know it represents a complex type. For complex types, the code uses a recursive call to merge the values in the complex type. The merged values for the complex type are then copied into the result using the SetValues method.

For scalar properties, the code compares the current value to the original value to see if the current user has edited the value. If the current user has edited the value, the current value is copied to the merged result. If the current user hasn’t edited the value but another user has changed it in the database, the database value is copied to the result. If nobody has edited the value, all three value collections agree and the value that was originally cloned can be left in the merged result.

If you want to test out the code, update the Main method to call ConcurrencyDemo and run the application.

The change tracking information that Entity Framework maintains is also useful if you want to log the changes that a user is making during SaveChanges. We’ll take a look at an example that writes the changes to the Console, but the techniques could be used for any number of logging or auditing solutions.

The logging output could get annoying if we leave it on for every example in this book, so we are going to introduce a flag that allows us to turn it on when we want to use it. Add the following property to your BreakAwayContext class:

public bool LogChangesDuringSave { get; set; }

You’ll need some helper methods to print out the required logging information. Add the two methods shown in Example 5-28 to your BreakAwayContext class. You’ll need to add a using statement for the System, System.Data, and System.Linq namespaces.

private void PrintPropertyValues(
  DbPropertyValues values,
  IEnumerable<string> propertiesToPrint,
  int indent = 1)
{
  foreach (var propertyName in propertiesToPrint)
  {
    var value = values[propertyName];
    if (value is DbPropertyValues)
    {
      Console.WriteLine(
        "{0}- Complex Property: {1}",
        string.Empty.PadLeft(indent),
        propertyName);

      var complexPropertyValues = (DbPropertyValues)value;
      PrintPropertyValues(
        complexPropertyValues,
        complexPropertyValues.PropertyNames,
        indent + 1);
    }
    else
    {
      Console.WriteLine(
        "{0}- {1}: {2}",
        string.Empty.PadLeft(indent),
        propertyName,
        values[propertyName]);
    }
  }
}

private IEnumerable<string> GetKeyPropertyNames(object entity)
{
  var objectContext = ((IObjectContextAdapter)this).ObjectContext;

  return objectContext
    .ObjectStateManager
    .GetObjectStateEntry(entity)
    .EntityKey
    .EntityKeyValues
    .Select(k => k.Key);
}

The PrintPropertyValues method is almost the same as the PrintPropertyValues you added to the Program class back in Example 5-10. The only difference is that this method accepts the names of the properties that should be printed, rather than printing all properties. As the name suggests, the GetKeyPropertyNames method will give you the names of the properties that make up the key of an entity. There is no way to get this information from the DbContext API, so the code uses the IObjectContextAdapter to get the underlying ObjectContext. You’ll learn more about IObjectContextAdapter in Chapter 8. The code gets the key property names by getting the EntityKey for the entity from the ObjectStateManager. ObjectStateManager is the ObjectContext equivalent to the DbContext.ChangeTracker.

With the helper methods in place, let’s write the logging code. The easiest way to run additional logic during the save process is to override the SaveChanges method on your derived context. The SaveChanges method on DbContext is virtual (Overrideable in Visual Basic) for exactly this purpose. Add the overridden SaveChanges method shown in Example 5-29 to your BreakAwayContext class.

public override int SaveChanges()
{
  if (LogChangesDuringSave)
  {
    var entries = from e in this.ChangeTracker.Entries()
                  where e.State != EntityState.Unchanged
                  select e;

    foreach (var entry in entries)
    {
      switch (entry.State)
      {
        case EntityState.Added:
          Console.WriteLine(
            "Adding a {0}",
            entry.Entity.GetType());

          PrintPropertyValues(
            entry.CurrentValues,
            entry.CurrentValues.PropertyNames);
          break;

        case EntityState.Deleted:
          Console.WriteLine(
            "Deleting a {0}",
            entry.Entity.GetType());

          PrintPropertyValues(
              entry.OriginalValues,
              GetKeyPropertyNames(entry.Entity));
          break;

        case EntityState.Modified:
          Console.WriteLine(
            "Modifying a {0}",
            entry.Entity.GetType());

          var modifiedPropertyNames =
            from n in entry.CurrentValues.PropertyNames
            where entry.Property(n).IsModified
            select n;

          PrintPropertyValues(
            entry.CurrentValues,
            GetKeyPropertyNames(entry.Entity)
              .Concat(modifiedPropertyNames));
          break;
      }
    }
  }

  return base.SaveChanges();
}

The code checks if the LogChangesDuringSave property is set to true—by default the property is set to false. If logging is enabled, the logging logic is executed. The code then locates the entries for all entities that are going to be saved—that’s all entities that aren’t in the Unchanged state. For each of these entities, the code identifies the change being performed and the type of entity it is being performed on. Then it prints out the values of some of the properties of the entity. The set of properties that gets printed depends on the type of operation being performed:

If you want to test the code out, add the TestSaveLogging method shown in Example 5-30.

private static void TestSaveLogging()
{
  using (var context = new BreakAwayContext())
  {
    var canyon = (from d in context.Destinations
                  where d.Name == "Grand Canyon"
                  select d).Single();

    context.Entry(canyon)
      .Collection(d => d.Lodgings)
      .Load();

    canyon.TravelWarnings = "Take a hat!";

    context.Lodgings.Remove(canyon.Lodgings.First());

    context.Destinations.Add(new Destination { Name = "Seattle, WA" });

    context.LogChangesDuringSave = true;
    context.SaveChanges();
  }
}

The code retrieves the Grand Canyon Destination and its related Lodgings from the database. The Grand Canyon Destination is then modified, one of its Lodgings is marked for deletion, and a new Destination is added to the context. The code then enables the logging you just added and calls SaveChanges. Update the Main method to call TestSaveLogging and run the application to see the log information in the console:

Adding a new Model.Destination
  - DestinationId: 0
  - Name: Seattle, WA
  - Country:
  - Description:
  - Photo:
  - TravelWarnings:
  - ClimateInfo:
Modifiying an existing System.Data.Entity.DynamicProxies.Destination_C0312EA59B82EAC711175D8C037E196179
A49BDE8FF3F0D6830DDB66725C841B
  - DestinationId: 1
  - TravelWarnings: Take a hat!
Deleting an existing Model.Lodging
  - LodgingId: 1

As expected, logging information is printed out for the three entities that are affected during SaveChanges. You’ll notice that the Lodging we modified has a strange type name—it’s not Model.Destination. This is because we enabled Destination as a change tracking proxy. The type name displayed is the type that Entity Framework creates at runtime that derives from the Model.Destination type.