Have the foreign key and navigation property synced immediately

Question

What do I have to do to have Entity Framework immediately sync the foreign key and the navigation property whenever either is changed, not just after calling SaveChanges?

public class Model
{
    [Key]
    public int ModelId { get; set; }

    public string Name { get; set; }

    public virtual Model Other { get; set; }

    [ForeignKey("Other")]
    public int OtherId { get; set; }

    // Other regular mapped properties not shown
}

I'm using EF 6.1.3 Code First. Change tracking is not explicitly deactivated and should be used.

I need this because my UI grid control changes the ID only (changing navigation object here causes trouble) but my business logic requires information from the referenced object immediately after the ID was changed, before saving the record. The referenced object's data determines what other options the user has to edit the record.

why do you need in such a way ? What is your business use case ? — Sampath, Aug 23 '16 at 07:36
Is `((IObjectContextAdapter)context).ObjectContext.DetectChanges()` what you are looking for? — Adil Mammadov, Aug 23 '16 at 07:38
My UI grid changes the ID only (changing navigation object here causes trouble) but my business logic requires information from the referenced object immediately after the ID was changed, before saving the record. — ygoe, Aug 23 '16 at 07:38
@AdilMammadov I'm not sure what that is. I prefer not to explicitly implement all auto-properties, that makes the code explode. I've read that EF should be able to do what I'm looking for, but nobody describes how to get there. — ygoe, Aug 23 '16 at 07:40
@ygoe, I have not said anything about *explicitly implementing all auto-properties* :). `DetectChanges` method should fix up identities, but you cannot call it directly on `DbContext`, so you get `ObjectContext` from `DbContext` by `((IObjectContextAdapter)context).ObjectContext`. And then call `DetectChanges` method of `ObjectContext`. — Adil Mammadov, Aug 23 '16 at 07:43
@AdilMammadov When should I call this method if not in the property setter? Also, I get the impression that ObjectContext is deprecated. — ygoe, Aug 23 '16 at 07:46
First of all, I am not sure that if will help you, but it should. As far as I know, there is no information about `ObjectContext` being *deprecated*. Also, adding entity to context should itslef match the keys. And you can call it where you want. After adding entity to context for example. If you are using *Repository* or *UnitOfWork* patterns you can add method inside them and call that method. Also, you can add property to your context to easyly access `ObjectContext` like `public ObjectContext ObjectContext { get { return ((IObjectContextAdapter)this).ObjectContext; } }` — Adil Mammadov, Aug 23 '16 at 07:53
I still guess that I have to call that method every time either property was changed, to update the other property, is that correct? — ygoe, Aug 23 '16 at 08:58

score 1 · Accepted Answer · edited May 23 '17 at 12:14

It seems that this question answers my question:

All mapped properties must be virtual. As soon as a single mapped property is not virtual, the whole thing doesn't work anymore and nobody tells you.

I haven't seen an easy way to verify that this is done, but if it is done, Entity Framework will apply some "More efficient change tracking" which also has the effect of foreign key properties updating navigation properties, and vice versa.

Oh, and this only works with Entity Framework proxy classes. You get these when querying existing objects, or with the DbSet.Create() method. Creating new instances of the model class directly won't do anything automatically.

Have the foreign key and navigation property synced immediately

1 Answers1

Linked