为什么不在WPF中使用BindingList

这可能很有趣:

http://www.themissingdocs.net/wordpress/?p=465

最重要的段落:

但是实现无法扩展，速度很慢，对于较大的列表，它的执行效果非常差.如果您的元素类型支持INotifyPropertyChanged，则每当其中一个元素引发属性更改事件时，整个列表便会遍历，以计算引发该事件的项目列表中的索引！当我第一次意识到这一点时，我感到震惊.您会看到BindingList实际上只是Collection上的一个相当薄的包装器，因此没有与每个条目关联的元数据，元素PropertyChanged事件的所有绑定都定向到单个处理程序，并且给出的所有内容都是源和名称属性的更改，因此如果不进行搜索就无法在ListChangedEventArgs中包括NewIndex参数. (默认情况下，该搜索甚至使用默认的对象比较器，因此，如果您碰巧在列表中有两个不同但有时相等的对象，请享受结果……)

But the implementation does not scale, it is slow, it performs terribly with larger lists. If your element type supports INotifyPropertyChanged, every time one of those elements raises the property changed event the entire list is walked to work out the index in the list of the item which raised the event! I was in shock when I first realised this. You see BindingList is truly just a rather thin wrapper over Collection, so there is no metadata associated with each entry, all of the binding of the element PropertyChanged event is directed to a single handler, and all it gets given is the source and the name of the changed property, so there is no way to include the NewIndex parameter in ListChangedEventArgs without doing a search. (By default this search even uses the default object comparator, so if you happen to have two different but sometimes equal objects in your list, enjoy the results…)

另一个便笺– AddNew，BindingList具有Collection所不具有的另一个功能–也无法缩放.它必须使用IndexOf来找出新添加的项目在列表中的何处，以防需要取消添加，因为它支持对派生类型进行自动排序. (BindingList本身不支持自动排序...)

Another side note – AddNew, the other feature which BindingList has which Collection does not – also does not scale. It has to use IndexOf to find out where in the list the newly added item ended up in case it needs to cancel the add, because it supports auto sorting in derived types. (BindingList does not support auto sorting itself…)