RejectChanges() with ViewModel and MVVM design pattern and UI update

Question

I am having a problem with DomainContext.RejectChanges() and reflecting the rollback in the UI. Here is my scenario.

1. I have a Model (Entity) generated for use with RIA services (I'll call it Foo)
2. I have a ViewModel that wraps Foo and extends it (I'll call it FooViewModel)
3. I have a View that is using Binding to display and update data using the FooViewModel
4. I have an "outer" ViewModel that holds an ObservableCollection of FooViewModels
5. The "outer" View has a list box bound to the ObservableCollection

So essentially there is a listbox of FooViewModels on one screen...when you select an item a childwindow is displayed to edit that particular FooViewModel. The FooViewModel is serving both the listbox and the childwindow.

Editing works just fine. A change in the childwindow reflects in the listbox immediately because I am calling RaisePropertyChanged() when the viewmodel properties are updated.

However, If I perform a DomainContext.RejectChanges()...the underlying entity gets rolled back (all changes reverted as expected)...however the FooViewModel isn't aware that this change has occurred and thus the UI isn't updated. If I reselect the item in the listbox on the first screen, the childwindow is displayed with the rolled back changes (which is what I want). The listbox still isn't updated though.

When I reject changes, if I kludge a RaiseProperyChanged() for the field that I changed...the UI listbox does update.

How do I get the UI to update when the underlying entity is rejected?? And how do I do it without tracking what properties of the viewmodel were rolledback? There has to be an easy way to accomplish this that I am just missing.

Answer 1

Something you could try is use the PropertyChanged event on the underlying entity Foo to trigger a RaisePropertyChanged pass on the FooViewModel properties.

so making some assumptions (so this code make sense):

1. You have a private variables in your FooViewModel
private Foo _foo;
private DomainContext _context;

2. You have a method on your FooViewModel that is calling RejectChanges() on your domain context.

Like so:

public void RejectChanges()
{
    _context.RejectChanges();
}

1. We have a method that raises the PropertyChanged event on our FooViewModel

Like so:

private void RaisePropertyChanged(string propertyName)
{
    var handler = PropertyChanged;

    if(handler != null)
        handler(this, new PropertyChangedEventArgs(propertyName);
}

Ok, now we have that established, lets have a look at exactly what happens when you call RejectChanges() on a domain context.

When you call RejectChanges() this bubbles down through the DomainContext to its EntityContainer, then to each EntitySet in that container and then to each Entity in the set.

Once there (and in the EntitySet), it reapplies the original values if there was any, removes the entity if it was added, or adds it if it was deleted. If there was changes to the values, then it applies them back to the properties.

So theoretically, all the RaisePropertyChanged(), that are generated in the entity properties, should be triggered.

NOTE: I haven't actually tested this. If this isn't the case, then none of this works :P

So we can hook into PropertyChanged event of the Foo entity, and raise the PropertyChanged event on our FooViewModel.

so our RejectChanges() method might look like this:

    public void RejectChanges()
    {
        Func<object, PropertyChangedEventArgs> handler = (sender, e) =>
            {
                RaisePropertyChanged(e.PropertyName);
            };

        _foo.PropertyChanged += handler;

        _context.RejectChanges();

        _foo.PropertyChanged -= handler;
    }

So we hook up an event handler to our Foo entity, which calls the FooViewModel.RaisePropertyChanged method with the property name that is changing on the Foo entity.

Then we reject changes (which triggers the property changes),

then we unhook the event handler.

Pretty long winded, but I hope this helps :)