INotifyCollectionChanged 的哪些实现实际上使用了移动和替换？答案

【问题标题】：Which implementations of INotifyCollectionChanged actually use move and replace?INotifyCollectionChanged 的哪些实现实际上使用了移动和替换？
【发布时间】：2016-06-21 06:57:39
【问题描述】：

我想知道该界面的现有使用者（我认为这将主要是绑定控件）使用界面的移动和替换事件，这些事件超出了仅通过添加和删除所能表达的范围。

特别是：它们是否真的被使用过，或者这只是一些历史文物？

【问题讨论】：

可以想象它们可以用于动画效果。如果你愿意，你可以search the source。
@Damien_The_Unbeliever 哇，我不知道他们有可在线搜索的资源。很高兴知道这一点。
注意 Args 构造函数。它主动确保为每种更改类型提供预期数据。

标签： .net xaml mvvm

【解决方案1】：

当你调用ObservableCollection<T>.Move(int, int)时你会得到一个移动动作。

当您替换一个项目时，您可能会假设相同的行为。但是ObservableCollection 上没有Replace 方法。你必须使用index accessor instead.

这些操作类型应始终由INotifyCollectionChanged 消费者处理。它们可用作防止额外操作的提示。

考虑一下，如果您有一个昂贵的集合图形表示，并且您调用了Remove，然后是Insert。集合缩小一个元素，然后立即增长一个元素。这可能会导致在删除索引后对所有元素进行两次重绘。 Replace 和 Move 让消费者知道集合的大小没有改变。

【讨论】：

我都知道。我的问题是它是否实际被消费者使用。
这个答案指出，作为接口的一部分，它绝对应该被处理。用列表框试试。将事件类型写入调试器，观察列表框的反应。
当然要处理。问题是列表框的处理方式是否与等效的添加/删除操作不同。不知道我只看 UI 会怎么看。
@John 控件对事件的确切反应很大程度上不在我们的掌控之中。我们所能假设的是，该项目将按照事件的指定被移动或替换。在列表框上，Remove(index 1) -> Insert(index 1, newItem) 在视觉上的行为与Replace(index 1, newItem) 完全相同。可能在较大的集合上存在明显的性能差异，但这是未指定的实现细节。不幸的是，唯一确定的方法是通过测试。

【解决方案2】：

它当然不是历史文物 - 它就在那里，所以你可以调用 Move，resp Replace 并且听众可以对它做出反应。没有它，无论内置控件是否使用它，界面都是不完整的。

不确定 ItemsControl 如何处理 CollectionChanged 事件，但我想 Move 和 Replace 事件也有一些逻辑。

毕竟 WPF 是开源的，你为什么不在这里查看：http://referencesource.microsoft.com/#PresentationFramework/src/Framework/System/Windows/Data/CollectionView.cs,4270b8e1bdd07308

如您所见，ItemsControl 使用的 CollectionView 对 Reset 和 Move 事件做出反应

【讨论】：

它不会是不完整的，因为移动和替换都可以表示为删除，然后是添加。
如果你先调用remove，那么就意味着item的数量发生了变化，这是不正确的。例如，ListBox 不必删除 ListBoxItem 再创建新的，但它可以重用现有的 ListBoxItem，这可能会产生显着的性能影响。
@John 我很困惑。我的回答告诉你为什么在发表评论前 40 分钟删除然后添加还不够好，你说你已经知道了。你能详细说明一下不够清楚的地方吗？
@Gusdor remove-then-add 是否足够正是问题所在，但尚未有人回答。你知道 ListBox 有这种性能优化吗？仅与性能有关吗？我可以查看来源并进行自己的研究，是的。我虽然问更快，但到底是什么。
你们俩都是真的。 John：Gusdor 想说的是，INotifyCollectionChanged 不应该只被 WPF 控件使用。您可以在业务逻辑甚至数据访问逻辑中使用它。在这种情况下，移动和替换事件可能是至关重要的，因此它绝对不是历史文物。 @Gudsor：你的回答中的陈述是正确的，但我觉得它不能满足这个问题。