10

概括

我有一个快速变化的大型数据集,我希望将其绑定到 UI(带分组的数据网格)。变化分为两个层面;

  • 经常从集合中添加或删除项目(单程每秒 500 个)
  • 每个项目都有 4 个属性,在其生命周期中最多会更改 5 次

数据的特点如下;

  • 收藏品中有约 5000 件商品
  • 可以在一秒钟内添加一个项目,然后进行 5 次属性更改,然后将其删除。
  • 一个项目也可能会在一段时间内保持某种临时状态,并且应该向用户显示。

我遇到问题的关键要求;

  • 用户应该能够按对象上的任何属性对数据集进行排序

我想做什么;

  • 仅每N秒更新一次 UI
  • 仅引发相关的 NotifyPropertyChangedEvents

如果项目 1 有一个属性状态,它在间隔内从 A -> B -> C -> D 移动,我需要/希望只引发一个“状态”更改事件,A->D。

我很欣赏用户不需要每秒更新数千次 UI。如果添加了一个项目,它的状态发生了变化,并且在 UI 更新之间 N 秒的窗口内全部删除,它不应该命中 DataGrid。

数据网格

DataGrid 是我用来显示数据的组件。我目前正在使用 XCeed DataGrid,因为它可以轻松地提供动态分组。我对它没有感情投入,如果我可以提供一些动态分组选项(其中包括经常更改的属性),股票 DataGrid 会很好。

我系统中的瓶颈目前是当一个项目的属性发生变化时重新排序所花费的时间

这会占用 YourKit Profiler 中 98% 的 CPU。

表达问题的另一种方式

给定两个最初相同的 BindingList / ObservableCollection 实例,但第一个列表此后有一系列附加更新(您可以收听),生成最小的更改集以将一个列表转换为另一个列表。

外部阅读

我需要的是 George Tryfonas 的这个ArrayMonitor的等价物,但被概括为支持添加和删除项目(它们永远不会被移动)。

注意,如果有人能想到更好的摘要,我将非常感谢他们编辑问题的标题。

编辑 - 我的解决方案

XCeed 网格将单元格直接绑定到网格中的项目,而排序和分组功能由 BindingList 上引发的 ListChangedEvents 驱动。这有点违反直觉,并排除了下面的 MontioredBindingList,因为行将在组之前更新。

相反,我自己包装项目,捕获属性更改事件并将它们存储在 HashSet 中,如 Daniel 建议的那样。这对我来说效果很好,我会定期迭代这些项目并要求他们通知任何更改。

MonitoredBindingList.cs

这是我对可以轮询更新通知的绑定列表的尝试。它可能存在一些错误,因为它最终对我没有用。

它创建一个添加/删除事件队列,并通过列表跟踪更改。ChangeList 与基础列表具有相同的顺序,因此在我们通知添加/删除操作后,您可以针对正确的索引提出更改。

/// <summary>
///  A binding list which allows change events to be polled rather than pushed.
/// </summary>
[Serializable]

public class MonitoredBindingList<T> : BindingList<T>
{
    private readonly object publishingLock = new object();

    private readonly Queue<ListChangedEventArgs> addRemoveQueue;
    private readonly LinkedList<HashSet<PropertyDescriptor>> changeList;
    private readonly Dictionary<int, LinkedListNode<HashSet<PropertyDescriptor>>> changeListDict;

    public MonitoredBindingList()
    {
        this.addRemoveQueue = new Queue<ListChangedEventArgs>();
        this.changeList = new LinkedList<HashSet<PropertyDescriptor>>();
        this.changeListDict = new Dictionary<int, LinkedListNode<HashSet<PropertyDescriptor>>>();
    }

    protected override void OnListChanged(ListChangedEventArgs e)
    {
        lock (publishingLock)
        {
            switch (e.ListChangedType)
            {
                case ListChangedType.ItemAdded:
                    if (e.NewIndex != Count - 1)
                        throw new ApplicationException("Items may only be added to the end of the list");

                    // Queue this event for notification
                    addRemoveQueue.Enqueue(e);

                    // Add an empty change node for the new entry
                    changeListDict[e.NewIndex] = changeList.AddLast(new HashSet<PropertyDescriptor>());
                    break;

                case ListChangedType.ItemDeleted:
                    addRemoveQueue.Enqueue(e);

                    // Remove all changes for this item
                    changeList.Remove(changeListDict[e.NewIndex]);
                    for (int i = e.NewIndex; i < Count; i++)
                    {
                        changeListDict[i] = changeListDict[i + 1];
                    }

                    if (Count > 0)
                        changeListDict.Remove(Count);
                    break;

                case ListChangedType.ItemChanged:
                    changeListDict[e.NewIndex].Value.Add(e.PropertyDescriptor);
                    break;
                default:
                    base.OnListChanged(e);
                    break;
            }
        }
    }

    public void PublishChanges()
    {
        lock (publishingLock)
            Publish();
    }

    internal void Publish()
    {
        while(addRemoveQueue.Count != 0)
        {
            base.OnListChanged(addRemoveQueue.Dequeue());
        }

        // The order of the entries in the changeList matches that of the items in 'this'
        int i = 0;
        foreach (var changesForItem in changeList)
        {
            foreach (var pd in changesForItem)
            {
                var lc = new ListChangedEventArgs(ListChangedType.ItemChanged, i, pd);
                base.OnListChanged(lc);
            }
            i++;
        }
    }
}
4

1 回答 1

5

我们在这里谈论两件事:

  1. 对集合的更改。这会引发事件INotifyCollectionChanged.CollectionChanged
  2. 对项目属性的更改。这会引发事件INotifyPropertyChanged.PropertyChanged

该接口INotifyCollectionChanged需要由您的自定义集合实现。该接口INotifyPropertyChanged需要由您的项目实现。此外,该PropertyChanged事件仅告诉您项目上的哪个属性发生了更改,而不是之前的值是什么。
这意味着,您的项目需要有一个类似这样的实现:

  • 有一个每N秒运行一次的计时器
  • 创建一个HashSet<string>包含所有已更改属性的名称。因为它是一个集合,所以每个属性只能包含一次或零次。
  • 更改属性时,将其名称添加到散列集中(如果它尚未包含在其中)。
  • 当计时器结束时,PropertyChanged为散列集中的所有属性引发事件,然后将其清除。

您的收藏将有类似的实现。然而,这有点困难,因为您需要考虑在计时器事件之间添加和删除的项目。这意味着,当添加一个项目时,您会将其添加到散列集“addItems”中。如果删除了某个项目,则将其添加到“removedItems”哈希集中,如果它尚未在“addItems”中。如果它已经在“addItems”中,请将其从那里删除。我想你明白了。

为了坚持关注点分离和单一职责的原则,最好让您的项目INotifyPropertyChanged以默认方式实现并创建一个合并事件的包装器。这样做的好处是您的项目不会被不属于那里的代码弄乱,并且这个包装器可以被制作成通用的并用于每个实现INotifyPropertyChanged.
集合也是如此:您可以为所有实现的集合创建一个通用包装器,INotifyCollectionChanged并让包装器合并事件。

于 2011-03-15T10:20:06.917 回答