为什么不在WPF中使用BindingList [英] Why NOT BindingList in WPF

问题描述

我也在MSDN论坛上也问过这个问题... http://social.msdn.microsoft .com/Forums/en/wpf/thread/4493988a-9bd8-48fe-aff0-348502136a80

I have asked this question on MSDN forums as well ... http://social.msdn.microsoft.com/Forums/en/wpf/thread/4493988a-9bd8-48fe-aff0-348502136a80

我需要知道为什么Microsoft建议在WPF中不正确支持BindingList ...

I need to know that why Microsoft suggests that BindingList is not properly supported in WPF...

在WPF中与BindingList不兼容的是什么?我发现它非常有用.到目前为止，我个人还没有发现BindingList速度变慢或内存负载增加.

What is it that doesnt work with BindingList in WPF? I find it pretty useful as it is. So far I personally have not found BindingList any slower or a having more load on memory.

Plus WPF ItemsControls，ItemsTemplates，Styles，Hierarchies也可以与BindingList s一起很好地工作.它们同样是可观察的.

Plus WPF ItemsControls, ItemsTemplates, Styles, Hierarchies work great with BindingLists too. They are equally observable.

我自己是WPF的核心开发人员，也是ObservableCollection的粉丝，我的信念因BindingList ....

Being a hardcore WPF developer myself and an ObservableCollection fan, my faith is getting shaken by a been-there-done-that BindingList....

为什么我应该在BindingList上使用ObservableCollection? (将INotifyPropertyChanged放在一旁，这两项都必须实现以更改项目属性)

Why should I use ObservableCollection over BindingList? (keeping aside INotifyPropertyChanged which both have to implement for item property changes)

推荐答案

这可能很有趣:

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…)

这篇关于为什么不在WPF中使用BindingList的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！