Как создать QAbstractItemModel для поддержки нескольких типов объектов и разных представлений

Question

Мне нужно написать класс QAbstractItemModel, который представляет иерархию различных типов объектов.В какой-то момент я хочу иметь возможность показать таблицу / список, содержащий только элементы уровня 1, только уровень 2 и т. Д.

Я работаю над анализатором сетевых протоколов, чем-то вроде wireshark.Я фиксирую socket.recv и socket.send события из процесса.В моей модели эти события называются NetworkEvent.Каждое сетевое событие может содержать один или несколько Packet.Каждый пакет имеет один или несколько Message, где сообщение на основе его кода анализируется как определенная структура.

Вот изображение иерархии классов программы:

В главном окне есть список и дерево.Я ожидаю, что смогу показать:

• таблица / список, содержащий только сетевые события, включая его атрибуты.
• таблица / список, содержащий только пакеты, включая его атрибуты.
• таблица / список, содержащий только пакеты на основе сетевого события.
• дерево, содержащее иерархию пакетов / сообщений (с полями и подструктурами)
• таблица / список, содержащий только сообщения
• таблица / список, содержащий только сообщения на основе пакета
• дерево, содержащее иерархию сообщений (с полями и подструктурами).

Поэтому я подумал, что лучшеИдея состояла в том, чтобы смоделировать QAbstractItemModel как дерево.Первая проблема, с которой я столкнулся, заключается в том, что, хотя у каждого класса есть понятие «дети», у каждого есть свое поле, представляющее детей, поэтому я должен позаботиться об этом внутри QAbstractItemModel.

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

Есть ли лучший или простой способ приблизиться к этому?Или это путь?

Answer 1

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

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

Возможно, вы захотите поэкспериментировать с представлениями списков, таблиц и деревьев, чтобы выяснить, что лучше всего подходит для ваших целей.Прелесть системы Model-View в том, что вы можете легко изменить View, когда у вас есть модель (ы).

Answer 2

Таким образом, вы создаете общее базовое семейство полиморфных классов и используете базовый указатель в качестве источника данных для модели.Одна единственная роль - объект данных, после чего отдельные делегаты могут получить доступ к своим конкретным полям данных, не беспокоясь о том, чтобы реализовать все с использованием ролей.Роль-ориентированный вариант использования действительно применим только для изоморфных наборов данных.

Затем вы можете настроить визуальное представление на основе фактического отдельного объекта и типа представления.

Я бы не женился на каком-либо конкретном представлении.Я бы реализовал только интерфейс списков, это дает больше гибкости при представлении структуры, вы можете рисовать простые списки в виде списка или табличного представления, а также вы можете иметь таблицы или деревья, которые состоят из списков списков.

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

Вам будет значительно проще реализовать это в QML, особенно фактическое визуальное представление, используяобщая объектная модель обозначена здесь .Хотя, если количество объектов очень велико, вы можете захотеть реализовать его как одну абстрактную модель элемента, вместо того чтобы каждый объект был моделью списка, чтобы избежать накладных расходов.Но если вы не имеете дело с миллионами и миллионами товаров, накладные расходы стоят того, чтобы их вернуть.