.net - 是什么导致 WPF ListCollectionView 使用自定义排序来重新排序其项目？

Question

考虑以下代码(出于示例目的而通用类型名称):

// Bound to ListBox.ItemsSource
_items = new ObservableCollection<Item>();

// ...Items are added here ...

// Specify custom IComparer for this collection view
_itemsView = CollectionViewSource.GetDefaultView(_items)
((ListCollectionView)_itemsView).CustomSort = new ItemComparer();

当我设置 CustomSort 时，集合会按照我的预期进行排序。

但是，我要求数据在运行时重新排序，以响应 Item 属性的更改。 Item 类派生自 INotifyPropertyChanged，我知道当我的数据模板更新屏幕上的值时，该属性会正确触发，只是不会调用排序逻辑。

我还尝试引发 INotifyPropertyChanged.PropertyChanged 传递空字符串，以查看通用通知是否会导致启动排序。没有香蕉。

编辑为了回应肯特的建议，我想我应该指出，使用它对项目进行排序具有相同的结果，即集合排序一次，但不随着数据变化重新排序:

_itemsView.SortDescriptions.Add(
    new SortDescription("PropertyName", ListSortDirection.Ascending));

Answer 1

我找到了this article by Dr. WPF首先回答我的问题，然后继续讨论调用 Refresh 对性能的影响。一些关键摘录:

Unfortunately, the Refresh() method results in a complete regeneration of the view. When a Refresh() occurs within the view, it raises a CollectionChanged notification and supplies the Action as "Reset". The ItemContainerGenerator for the ListBox receives this notification and responds by discarding all the existing visuals for the items. It then completely regenerates new item containers and visuals.

然后，他描述了一种可以提高性能的巧妙解决方法。而不是调用刷新、删除、更改然后重新添加项目。

我本以为 ListView 可以跟踪更改的项目并知道在 View 中单独重新定位该项目。

.NET 3.5 SP1 中引入了一种新方法涉及接口(interface) IEditableObject，该接口(interface)通过使用 BeginEdit()、CancelEdit() 和 EndEdit 方法将数据绑定(bind)到模板来提供事务编辑()。阅读 the article了解更多信息。

编辑为 user346528 points out , IEditableObject 实际上并不是 3.5SP1 中的新内容。它实际上看起来已经在框架中 since 1.0 .