为什么ObservableCollection不支持批量更改？

ObservableCollection支持AddRange或RemoveRange等操作引起的潜在问题是什么？由于ObservableCollection经常与WPF一起使用，因此必须有微软没有提供它们的原因。

您可以实现自己的集合来支持批量操作并实现INotifyCollectionChanged 。如果我将这样的控件绑定到ItemsControl会发生什么？

有谁知道不支持批量更改的ItemsControls？

我不认为有任何潜在的缺点或问题，只是它不存在。实际上，您会发现’System.Collections.Generic’中的大多数类型也不提供’AddRange’function。

同时，很多人创建了自己的’ObservableCollection’版本，以提供您想要的function。 INotifyCollectionChanged包含足够的信息供其处理程序记录，因为这个原因可能会影响一系列项目。

最后但并非最不重要的是，如果您绑定具有这些“范围”类型操作的集合，您会发现它们将按预期使用您的UI

ObservableCollection有很多扩展，可以在互联网上找到添加/删除范围的概念，或者允许您推迟更新并手动触发它们。例如，请参阅此Stack Overflow问题：

ObservableCollection不支持AddRange方法，所以除了INotifyCollectionChanging外，我还会收到添加的每个项目的通知？

您还可以实现触发重置事件的批量添加，这将导致UI重新呈现集合中的所有项目：

这些允许您更有效地管理UI更新。 ItemsControl如何处理集合更改事件，详细说明已更改项目的列表取决于WPF框架本身。我假设它智能地处理这个！

我的建议是，如果性能对您至关重要，并且您的集合中有大量项目正在更新并且遇到性能问题，那么ObservableCollection子类ObservableCollection以最适合您应用程序需求的方式管理集合更改通知。

NotifyCollectionChangedEventArgs包含索引信息。删除项目会导致索引重新洗牌，插入项目也是如此。因此，虽然并非完全不可能，但提供使用范围的能力将相当困难并且可能效率低下。

必须有一个理由为什么微软不提供它们

它们并不提供所有可能的function，它（也）是成本与需求的关系。

您可以实现自己的集合来支持批量操作并实现INotifyCollectionChanged 。

是。当你这样做时，你会发现该集合必须选择如何/何时传播这些变化。我从未尝试过，但我想有一些权衡，View或ViewModel可以做出比可重用集合更好的决策。