Editing ObservableCollection's SelectedItem Without Bound Controls Seeing Edits Until They Are Saved

I have a view containing a ListView and an "Edit" Button. The ListView's ItemSource is bound to an ObservableCollection<Account> property on the underlying view model. Its SelectedItem property is also bound to the view model.

When the edit button is clicked, the existing view model launches an editing view/view model pair ("editing screen") allowing the user to edit the currently selected Account. The Account to edit is determined by the main view model's SelectedItem property.

Problem: Any changes made in the editing screen are immediately reflected in the other screen's ListView, even before the edit screen's "Save" button is clicked. Why this happens makes sense--Account is raising property change events when its properties are changed and the ListView is processing those notifications.

Desired Outcome: Bound controls (like the ListView) should only see editing screen changes after"Save" is clicked.

Possible Solutions

• Suspend Account's property change notifications while editing is underway. Disadvantages: If a manual data-binding update is performed while an Account instance is being edited, the "in-progress" changes will appear on the ListView even though those changes haven't been raising notifications. Also, if the user launches a second edit window for the same Account, they will see the "in-progress" changes. Idea rej开发者_JAVA百科ected.
• Have the editing screen view model wrap the Account instance in some kind of EditingAccount class that copies changes made to it back to the original Account only when Save() is called. Should the editing screen take on the responsibility of facilitating this wrapping or should it ask the service layer to do it?

What do you think of these options? How do you solve this problem when you encounter it?

---

I would go with some version of the second option. Basically this is a variation of the MVVM pattern which is considered the "right" way to do WPF/Silverlight code. Basically you should have a ModelView object for each "screen" (View) that wraps the model and exposes the model in a format specific to the View so it does exactly what the View needs and NO MORE.