Question

I am using Entity Framework and Code First approach in a WPF MVVM application backed by a SQL CE database. I am trying to design a model class that can simply update one of its property values in response to another one of its property values changing. Basically, I am looking for a way to define a poco that is “self-tracking” after the instance is initialized by EF. If the answer involves abandoning Code First, then maybe that is the only viable route (not sure). A basic example:

class ThingModel
{
    public int Id { get; set; }

    public bool OutsideDbNeedsUpdate { get; set; }

    private string _foo;

    public string Foo
    {
        get { return _foo; }

        set
        {
            if (_foo != value)
            {
                _foo = value;

                OutsideDbNeedsUpdate = true;
            }
        }
    }
}

However, the problem with the above is that whenever DbContext is initializing an instance at runtime and setting the fields, my class is prematurely setting the dependent field in response. In other words, I am searching for a simple pattern that would allow my poco class to ONLY do this special change tracking after EF has finished initializing the fields on an instance.

I realize I could do something like the solution here
but my business case requires that this special change tracking be decoupled from the EF change tracking, in other words, I require the ability to SaveChanges regardless of the state of the HasChanges property above. This is because I would like to be able to periodically check the HasChanges property on my entities and in turn update dependent values in an outside database (not the same one backing the EF DbContext) and many changes/saves may happen to the EF DB between pushes to the outside DB. Hence the reason I was hoping to just persist the flag with the record in my DB and reset it to false when the periodic update to the outside DB occurs.

Answer 1

After your edit I think you can use the ObjectMaterialized event.

This event is raised after all scalar, complex, and reference properties have been set on an object, but before collections are loaded.

Put this in the constructor of your DbContext:

((IObjectContextAdapter)this).ObjectContext.ObjectMaterialized +=
    HandleObjectMaterialized;

And the method:

private void HandleObjectMaterialized(object sender, ObjectMaterializedEventArgs e)
{ }

Now the question is, what to put in the method body? Probably the easiest solution is to define an interface

interface IChangeTracker
{
    bool Materialized { get; set; }
    bool OutsideDbNeedsUpdate { get; }
}

and let the classes you want to track implement this interface.

Then, in HandleObjectMaterialized you can do:

var entity = e.Entity as IChangeTracker;
if (entity != null)
{
    entity.Materialized = true;
}

After this you know when you can set OutsideDbNeedsUpdate internally.

---

Original text

Generally it is not recommended to have properties with side effects (well, more exact, with more side effects than changing the state the represent). Maybe there are exceptions to this rule, but most of the time it is just not a good idea to have dependencies between properties.

I have to guess a bit what you can do best, because I don’t know what your real code is about, but it might be possible to put the logic in the getter. Just an example:

public State State
{
   get { return this.EndDate.HasValue ? MyState.Completed : this._state; }
   set { this._state = value; }
}

This does not remove the mutual dependencies, but it defers the moment of effect to the time the property is accessed. Which in your case may be not sooner than SaveChanges().

Another strategy is making a method that sets both properties at once. Methods are expected to have side effects, especially when their names clearly indicate it. You could have a method like SetMasterAndDependent (string master).

Now methods are not convenient in data binding scenarios. In that case you better let the view model set both properties or call the method as above.