Apr 15, 2011 at 2:07 PM
Edited Apr 15, 2011 at 2:09 PM
@bennage: every time you update your collection from a thread that is not a Dispatcher thread you can incour in a problem. To be more specific, since you can add items into the collection asynchronously, then dispatch the notification, it is possible that
other parts of the WPF framework access to the updated collection before all the elements involved in the UI representation have been notified. In my case, I noticed that a list bound to such collection had duplicated visual elements.
The fact is that if you notify and dispatch synchronously, you are confident that the WPF pipeline has all the information required.
When you speak of 'performance' you are only referring to the perceived responsiveness of your UI. When you decouple collection modification and notification, probably you are using two different Dispatcher cycles while the default implementation uses a
To understand the difference between the approaches, consider the following example:
var myCollection = new BindableCollection();
Debug.Assert(myCollection.Count == 1);
1. In the current implementation, the following code may fail if the thread executing such code is not the Dispatcher. This forces people to ensure thread affinity on the VM, thus ensuring that race conditions are avoided.
2. In your implementation, the same code cannot fail, and hides the fact that there is some thread synchronization to be dealt with. If you ignore this fact, there is a chance that the UI layer 'sees' a callection which is different from the expected one.
This can lead to effects similar to race conditions, since objects listening to the collection notification are not synchronized with the collection itself.
Probably this is not the best explanation of the issue, but I suppose I gave you enough hints to think about it.
On a final note, you can consider that since the VM is just a model of the View, you need to ensure that VM code is thread safe.