Came a cross some unexpected behaviour from the CancelEdit() method that was frustrating to figure out.
I'll start at the beginning. My first issue was that CancelEdit on a large object graph under Silverlight (that is bound to many UI elements), is very slow, but more importantly it blocks the UI thread until CancelEdit completes. For our scenario the 2-3 second delays are yielding an unacceptable bad user experience.
Possible feature request: Provide support for calling CancelEditAsync() or implementing it so that it doesn't block??
So during my investigation, I found that all the various Silverlight controls and other dependency properties that are bound to the CSLA business object, is contributing to the slow behaviour.
One possible solution to the blocking of the UI, was to first create a Clone() of the business object, then call CancelEdit() on that clone. Once done, I then replace the Model property on my ViewModel with the cloned instance (which will have all the dependencies rebind to the new Model instance).
Success! The user experience is substantially better, until I discovered that the CancelEdit() behaved differently on the clone than on the original instance. Specifically I've lost data. I quadruple-checked and found that if I call CancelEdit() on the original object without cloning it first, data is not lost. However if I clone it first, then I lose data.
So what do I mean with lose data? In my case I have a freshly fetched business object that is not dirty. The object is an editable root that includes a child property composing an editable child collection of editable children.
What I mean by data lost is that this editable child collection is suddenly empty where previously there were children (that weren't dirty either). Calling CancelEdit() on the original instance does not clear this collection.
(Though I'm not sure it's relevant, this children have grand children, etc. and there are other child properties on the root too.)
Any ideas?
Jaans