Update "one to many" relationships with separate associations using Entity Framework, Code First.

associations code-first dbcontext entity-framework


It took me way too long to find a solution to the scenario described below. What should seemingly be a simple affair proved to be rather difficult. The question is:

Using Entity Framework 4.1 (Code First approach) and "Independent associations" how do I assign a different end to an existing "many to one" relationship in a "detached" scenario ( Asp.Net in my case).

The model:

I realize that using ForeignKey relationships instead of Independent Associations would have been an option, but it was my preference to not have a ForeignKey implementation in my Pocos.

A Customer has one or more Targets:

    public class Customer:Person
    public string Number { get; set; }
    public string NameContactPerson { get; set; }
    private ICollection<Target> _targets;

    // Independent Association
    public virtual ICollection<Target> Targets
        get { return _targets ?? (_targets = new Collection<Target>()); }
        set { _targets = value; }

A Target has one Customer:

    public class Target:EntityBase
    public string Name { get; set; }
    public string Description { get; set; }
    public string Note { get; set; }
    public virtual Address Address { get; set; }
    public virtual Customer Customer { get; set; }

Customer derives from a Person class:

    public class Person:EntityBase
    public string Salutation { get; set; }
    public string Title { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set  ; }        
    public string Telephone1 { get; set; }
    public string Telephone2 { get; set; }
    public string Email { get; set; }        

    public virtual Address Address { get; set; }

EntityBase class provides some common properties:

    public abstract class EntityBase : INotifyPropertyChanged
    public EntityBase()
        CreateDate = DateTime.Now;
        ChangeDate = CreateDate;
        CreateUser = HttpContext.Current.User.Identity.Name;
        ChangeUser = CreateUser;
        PropertyChanged += EntityBase_PropertyChanged;

    public void EntityBase_PropertyChanged(object sender, PropertyChangedEventArgs e)
        if (Id != new Guid())
            ChangeDate = DateTime.Now;
            ChangeUser = HttpContext.Current.User.Identity.Name;

    protected virtual void OnPropertyChanged(PropertyChangedEventArgs e)
        PropertyChangedEventHandler handler = PropertyChanged;
        if (handler != null) handler(this, e);

    public event PropertyChangedEventHandler PropertyChanged;

    public Guid Id { get; set; }
    public DateTime CreateDate { get; set; }
    public DateTime? ChangeDate { get; set; }
    public string CreateUser { get; set; }
    public string ChangeUser { get; set; }

The Context:

    public class TgrDbContext : DbContext
    public DbSet<Person> Persons { get; set; }
    public DbSet<Address> Addresses { get; set; }
    public DbSet<Customer> Customers { get; set; }
    public DbSet<Target> Targets { get; set; }
    public DbSet<ReportRequest> ReportRequests { get; set; }

    // If OnModelCreating becomes to big, use "Model Configuration Classes"
    //(derived from EntityTypeConfiguration) instead
    protected override void OnModelCreating(DbModelBuilder modelBuilder)
        modelBuilder.Entity<Person>().HasOptional(e => e.Address);            
        modelBuilder.Entity<Customer>().HasMany(c => c.Targets).WithRequired(t => t.Customer);            

    public static ObjectContext TgrObjectContext(TgrDbContext tgrDbContext)
        return ((IObjectContextAdapter)tgrDbContext).ObjectContext;
11/12/2015 10:03:26 PM

Accepted Answer

I waited for @Martin answer because there are more solutions for this problem. Here is another one (at least it works with ObjectContext API so it should work with DbContext API as well):

// Existing customer
var customer = new Customer() { Id = customerId };
// Another existing customer
var customer2 = new Customer() { Id = customerId2 };

var target = new Target { ID = oldTargetId };
// Make connection between target and old customer
target.Customer = customer;

// Attach target with old customer
// Attach second customer
// Set customer to a new value on attached object (it will delete old relation and add new one)
target.Customer = customer2;

// Change target's state to Modified
context.Entry(target).State = EntityState.Modified;

The problem here is internal state model and state validations inside EF. Entity in unchanged or modified state with mandatory relation (on many side) cannot have independent association in added state when there is no other in deleted state. Modified state for association is not allowed at all.

8/7/2011 9:20:14 PM

Popular Answer

There is a lot of information to be found on this topic; on stackoverflow I found Ladislav Mrnka's insights particularly helpful. More on the subject can also be found here: NTier Improvements for Entity Framework and here What's new in Entity Framework 4?

In my project (Asp.Net Webforms) the user has the option to replace the Customer assigned to a Target object with a different (existing) Customer object. This transaction is performed by a FormView control bound to an ObjectDataSource. The ObjectDataSource communicates with the BusinessLogic layer of the project which in turns passes the transaction to a repository class for the Target object in the DataAccess layer. The Update method for the Target object in the repository class looks like this:

    public void UpdateTarget(Target target, Target origTarget)
            // It is not possible to handle updating one to many relationships (i.e. assign a 
            // different Customer to a Target) with "Independent Associations" in Code First.
            // (It is possible when using "ForeignKey Associations" instead of "Independent 
            // Associations" but this brings about a different set of problems.)
            // In order to update one to many relationships formed by "Independent Associations"
            // it is necessary to resort to using the ObjectContext class (derived from an 
            // instance of DbContext) and 'manually' update the relationship between Target and Customer. 

            // Get ObjectContext from DbContext - ((IObjectContextAdapter)tgrDbContext).ObjectContext;
            ObjectContext tgrObjectContext = TgrDbContext.TgrObjectContext(_tgrDbContext);

            // Attach the original origTarget and update it with the current values contained in target
            // This does NOT update changes that occurred in an "Independent Association"; if target
            // has a different Customer assigned than origTarget this will go unrecognized
            tgrObjectContext.AttachTo("Targets", origTarget);
            tgrObjectContext.ApplyCurrentValues("Targets", target);

            // This will take care of changes in an "Independent Association". A Customer has many
            // Targets but any Target has exactly one Customer. Therefore the order of the two
            // ChangeRelationshipState statements is important: Delete has to occur first, otherwise
            // Target would have temporarily two Customers assigned.
                o => o.Customer,

                o => o.Customer,

            // Commit
            tgrObjectContext.Refresh(RefreshMode.ClientWins, origTarget);
        catch (Exception)

This works for the Update method for the Target object. Remarkably, the procedure for inserting a new Target object is way easier. DbContext recognizes the Customer end of the independent association properly and commits the change to the database without further ado. The Insert method in the repository class looks like this:

        public void InsertTarget(Target target)
        catch (Exception)

Hopefully this will be useful to somebody dealing with a similar task. If you notice a problem with this approach described above, please let me know in your comments. Thanks!

Related Questions


Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow