.NET 需要一个真正的数据感知和数据驱动网格，使用 GUID 作为行句柄

Question

我正在寻找适用于 .NET 的数据感知网格，该网格已针对底层数据集的重复更改进行了优化。我将举一个例子来展示我在该上下文中优化的含义，因为几乎所有网格都允许您更改数据源。但追溯到 OCX 时代，更改数据源已经给数据感知网格带来了问题。

这种数据感知的数据驱动网格不得使用整数行句柄。 它必须使用 GUID 行句柄。这是该网格最重要的一个要求。

底层数据集的每一行都分配有一个 GUID rowHandle，而不是整数，无论​​数据行如何排序或分组，数据行的 GUID rowHandle 都会保留下来，并且可以通过其 rowHandle 立即检索数据行。

当当前焦点行的 GUID 与最近获得焦点的行的 GUID 不同时，会触发网格的 FocusedRowChanged 事件。 [编辑：在使用整数行句柄的网格，通常情况下，当数据源更改时， FocusedRowChanged 事件不会触发，因为焦点行位置尚未更改；例如，焦点位于数据源更改之前的第一行，焦点位于数据源更改之后的第一行；即使底层行数据完全不同，整数行句柄也是相同的。]

我希望网格的行为真正具有数据感知和数据驱动；例如

Grid.GroupByColumnNames = {"customername","city"};
Grid.Groups["customername"].ExpandedValues = {"Acme Widgets", "Foo Industrial"};
Grid.Groups["city"].ExpandedValues = {"New York","Miami"};

，现在，如果我清除了上面网格下方的数据集，并用另一个数据集替换其数据源，该数据源也有客户名和城市列，并且该列中包含值 Acme Widgets 和 Foo Industrial，则网格将按customername 和 city 列，并展开这些公司（如果 PreserveGroupingsWhenDataSetChanges 标志设置为 True）。

Answer 1

这个问题有根本性的错误，这就是为什么几个月后没有人提供一个好的答案。即使数据的主键是 GUID，也不能证明控件的行句柄是 GUID。事实上这是一个非常糟糕的主意。 GUID 为 128 位（16 字节），而 int 通常为 32 位 - 但比位数（在某些环境中为 64）更重要的是 int 操作是原子的，这意味着您可以读取/写入 int，而无需在之间锁定线程并且性能更高。因此 GUID 具有更高的内存占用和更高的处理成本（读/写每个都需要多个操作）。

因此，实际上任何控件都应该在视觉上使用快速/精益代码，并在必要时引用数据源来获取主键或其他数据位。

我对网格的体验和想法

我碰巧喜欢 winforms 的 DevExpress 控件，也使用它们的数据层组件 XPO。然而，有多个组件供应商具有类似的控件和数据层（通常都共享将行句柄与数据主键分离的功能）。

在 DevExpress 中，他们有一个出色的数据感知网格，并提供大量事件供您关联各种可能的更改。

XPO 数据层可以使用任何内容作为主键，包括 int 或 Guid。我与许多其他开发人员一起使用 Guid，因为它能够从远程计算机或离线数据插入主键（我不能说我曾经负责过表中记录超过 20 亿条的数据库，但是也许你是）。

虽然我的数据的主键可能是 GUID，但行句柄仍然是整数。这在幕后会比 Guid 快得多。然而，它们仍然提供了一堆在可视索引、行句柄和数据源索引之间来回切换的方法，以及一些通过行句柄获取底层数据源行的方法。这在许多提供行句柄（而不是数据主键）的控件事件中非常有用，您只需使用一行代码即可通过行句柄获取数据源记录。

另外，一般来说，如果您使用基于字符串的索引器访问集合，如上面的伪代码所示，组件只需在幕后执行 List.IndexOf() 类型的调用，然后将其传递给索引器为 int 索引。所以你实际上仍在幕后使用基于 int 的索引。即使某些组件公司将 GUID 用于行句柄，他们也会在幕后将这些 GUID 放入哈希集或字典中，以查找实际使用的 int 索引。因此，无论如何，这一切都只是整数之上的层，因此他们只是将其抽象化，并让您在需要时在代码中实现此类内容（而不是将其构建到组件库中）。

建议

最重要的是，我认为您可以使用 DevExpress Grid 完成上面描述的所有内容，但必须放弃 GUID 行句柄并稍微改变您的策略。如果您的应用程序需要这种反向查找，您可能需要构建自己的 GUID 以将行句柄索引作为哈希集或字典。如果所有行句柄始终都是 GUID，这可以帮助您避免性能问题，但仍然可以在 GUID 和行句柄之间进行向前和向后转换。