Это ситуация, когда архитектура Qt Model / View бесполезна?

Question

Я пишу приложение на основе графического интерфейса, где я читаю строку значений из последовательного порта каждые несколько секунд, и мне нужно отобразить большинство значений в графическом индикаторе какого-то типа (возможно, я думал о QprogressBar), который отображает диапазон и Значение. Некоторые из других данных, которые я анализирую из строки, - это дата и коды ошибок. Также данные являются иерархическими.

Я хотел использовать архитектуру модель / представление Qt, потому что какое-то время меня интересовали вещи MVC, но я никогда не думал о том, как реализовать это очень хорошо.

На данный момент у меня есть подкласс QAbstractItemModel, и в модели я читаю последовательный порт и оборачиваю элементы, проанализированные из строки, в структуру данных Tree. Я могу просматривать все данные в QtreeView без проблем.

Я также начал создавать подкласс QAbstractItemView для создания своего собственного представления со всеми графическими индикаторами и тому подобным. Вот где я застреваю. Мне кажется, что для разработки представления, которое знает, как отображать мою пользовательскую модель, представление должно точно знать, как организованы все данные в модели. Разве это не противоречит цели Model / View? QTreeView, с которым я тестировал модель, в основном просто отображает модель в том виде, как она настроена в древовидной структуре, но я не хочу этого делать, потому что данные не всех одного типа. Является ли тип данных или то, как вы хотели бы представить их пользователю, определяющим фактором того, стоит ли использовать эту архитектуру или нет? Я всегда предполагал, что всегда лучше проектировать в стиле MVC.

Мне кажется, что было бы лучше просто создать подкласс QWidget, а затем прочитать его с последовательного порта и обновить все подвиджеты (графические индикаторы, метки и т. Д.) Из подкласса. По сути, делайте все в одном классе.

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

Большое спасибо за любую помощь!

Answer 1

** ** - Это ситуация, когда архитектура Qt Model / View бесполезна?
Я скажу не обязательно - конец редактирования

Я не уверен, что полностью понимаю ваш вопрос, но позвольте мне попробовать.

Сначала поговорим о шаблоне отображения MVC. Этот шаблон полностью разбивает программу на отдельные (и, надеюсь, проверяемые) разделы, которые имеют свои собственные проблемные области.

1. Модель представляет собой структуры данных, которые описывают ваши данные. Я уверен, что здесь есть некоторые статистические данные. Важно, чтобы модель ничего не знала о том, как данные будут отображаться пользователю.
2. Вид - это способ представления информации пользователю. Не следует заботиться о том, как данные представлены для отображения. Для этого слоя важно не знать, как модель получает данные для отображения.
3. Управляющая логика - это «клей», соединяющий первые два элемента. Это слой, который содержит все «грязные» вещи, чтобы сделать их удобными для пользователя. EDIT - Большую часть того, что QT называет «элементом просмотра», я бы, вероятно, поместил на уровень контроллера.

Но если вы сделаете это, то уровни модели и контроллера станут очень тестируемыми.

С учетом вышесказанного, многие из ваших пунктов на самом деле не связаны с паттерном MVC. Похоже, вы обсуждаете, как оптимально отобразить данные. Это всегда проблема. И, не видя вашего приложения, я не собираюсь рассказывать вам, что будет хорошо выглядеть.

Но, следуя хорошему дизайну паттернов MVC, вы можете сделать довольно значительный пересмотр дисплея, не влияя на нижележащий код.

Как говорится, я сейчас занимаюсь именно этой проблемой, и эта схема хорошо работает для меня. Если вы зайдете на codeplex.com и поищете mvvm (model-view-viewmodel, термин, используемый в WPF), вы увидите несколько проектов, использующих его, которые вы можете использовать для получения дополнительной информации.

Если этого недостаточно, дайте мне знать, и я смогу дать вам лучший ответ.