нужна действительно ориентированная на данные и управляемая данными сетка для .NET, которая использует GUID в качестве дескрипторов строк

Question

Я ищу сетку с учетом данных для .NET, которая была оптимизирована для повторяющихся изменений базового набора данных.Я приведу пример, чтобы показать, что я подразумеваю под оптимизацией в этом контексте, поскольку почти все сетки позволяют вам изменять источник данных.Но возвращаясь ко временам OCX, изменение источника данных вызвало проблемы для сеток с поддержкой данных.

Эта управляемая данными сетка с данными не должна использовать целочисленные дескрипторы строк. Он должен использовать дескрипторы строк GUID .Это самое важное требование этой сетки.

Каждой строке базового набора данных присваивается идентификатор GUID rowHandle, а не целое число, и независимо от того, как датары оказываются отсортированными или сгруппированными, идентификатор GUID строки данных остается с ним, и данные можно получить мгновенно.своей строкой.

Событие FocusedRowChanged сетки вызывается, когда GUID текущей в фокусе строки не совпадает с GUID строки, в которой последний раз был фокус. [РЕДАКТИРОВАТЬ: В сетке, которая использует целочисленные дескрипторы строк, часто бывает так, что при изменении источника данных событие FocusedRowChanged не сработает, потому что позиция фокусированного ряда не изменилась;например, фокус был на первой строке до изменения источника данных, и фокус был на первой строке после изменения источника данных;целочисленный дескриптор строки один и тот же, даже если базовые данные строки совершенно разные.]

Я хочу, чтобы сетка действительно учитывала данные и управлялась данными в своем поведении;например,

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

Теперь, если я очистил набор данных, лежащую в основе сетку выше и заменил другой набор данных своим источником данных, который также имел столбцы с именами клиентов и города и содержал значения Acme Widgets и Foo Industrial в этом столбце,сетка будет группировать новый набор данных по столбцам имени клиента и города и расширять эти компании (если для флага PreserveGroupingsWhenDataSetChanges установлено значение True).

Answer 1

В этом вопросе есть что-то принципиально неправильное, поэтому по прошествии нескольких месяцев никто не дал хорошего ответа. Даже если первичным ключом ваших данных является GUID, это не оправдывает, что дескрипторы строки для элемента управления являются GUID. На самом деле это довольно плохая идея. GUID - это 128 бит (16 байт), в то время как целые, как правило, 32-битные, но важнее, чем количество бит (скажем, было 64 в некоторых средах), что операции int являются атомарными, то есть вы можете читать / записывать int без блокировки между темы и более высокая производительность. Таким образом, GUID имеют больший объем памяти и более высокую стоимость обработки (чтение / запись будет состоять из нескольких операций каждая).

Так что на самом деле любой элемент управления должен визуально использовать быстрый / обедненный код и просто ссылаться на источник данных при необходимости для получения первичного ключа или других битов данных.

Мой опыт работы с сетями и мысли о ней

Мне нравятся элементы управления DevExpress для winforms, а также я использую их компонент уровня данных XPO. Однако есть несколько поставщиков компонентов со схожими элементами управления и уровнями данных (которые, как правило, все разделяют функцию отделения дескрипторов строк от первичных ключей данных).

В DevExpress у них есть отличная сетка, которая является Data Aware и предоставляет множество событий, которые вы можете использовать для всех возможных изменений.

Там слой данных XPO может использовать что угодно для первичного ключа, включая int или Guid. Я использую Guids вместе со многими другими разработчиками из-за возможности вставлять первичные ключи с удаленных машин или автономных данных (я не могу сказать, что когда-либо отвечал за базу данных с более чем 2 миллиардами записей в таблице, но может быть, вы).

Хотя первичным ключом для моих данных может быть GUID, дескрипторы строк по-прежнему целочисленные. Это будет значительно быстрее за кулисами, чем Guid. Тем не менее, они по-прежнему предоставляют набор методов для перехода между визуальным индексом, дескриптором строки и индексом источника данных, а также несколько методов для выборки базовой строки источника по дескриптору строки. Это полезно во многих событиях элемента управления, которые предоставляют дескрипторы строк (не первичные ключи данных), где вы просто захватываете запись источника данных за дескриптор строки с одной строкой кода.

Кроме того, вообще говоря, если вы обращаетесь к коллекции с помощью строкового индексатора, как в приведенном выше псевдокоде, компоненты просто выполняют некий вызов List.IndexOf() за кулисами, который затем передается индексатору в виде индекса int , Таким образом, вы все еще работаете с индексами на основе int за кулисами. Даже если бы какая-то компания-производитель использовала GUID для дескрипторов строк, они поместили бы эти GUID в хэш-набор или словарь за кулисами, чтобы найти индекс int для фактического использования. Так что в любом случае все это будет слоями поверх целых, поэтому они просто оставляют это абстрактным и позволяют вам реализовывать такие вещи в вашем коде, если вам это нужно (в отличие от встраивания в библиотеку компонентов).

Рекомендация

Суть в том, что я думаю, что вы можете выполнить все, что вы описали выше, с помощью DevExpress Grid, но вам придется отпустить дескрипторы строк GUID и немного изменить свою стратегию. Вам может понадобиться создать свой собственный GUID для индекса строки как хэш-набора или словаря, если ваше приложение требует такого обратного просмотра. Это избавит вас от проблем с производительностью, если все дескрипторы строк всегда были GUID, но все же даст вам прямой и обратный перевод между GUID и дескрипторами строк.