Если класс производного класса QAbstract * принадлежит бэкенду

Question

У меня есть приложение, в котором я хочу иметь строгое разделение между бэкэнд и интерфейсом (GUI).

Бэкэнд - логика приложения с классами cpp, а интерфейсом являются файлы QML с некоторыми классами cpp, которые в основном работают как адаптеры к серверу.

Теперь мне было интересно, есть ли у вас классы, полученные из QAbstract * Model в бэкэнд-форме, с точки зрения дизайна.

Моя первая мысль состояла в том, что они НЕ должны принадлежать серверу, потому что они всего лишь обертка вокруг некоторых классов контейнеров Qt, чтобы отражать их данные в графическом интерфейсе. Таким образом, можно вводить указатель на фактические данные, и их следует использовать только в интерфейсе для отображения цели, но они не должны использоваться нигде в бэкэнд.

Класс Qt Container, конечно, должен принадлежать бэкэнд.

Теперь мне также нужны некоторые функции преобразования и утилиты, которые действуют и, возможно, изменят данные контейнеров. Поэтому я написал класс «обработчик». Но теперь становится все труднее держать все в синхронизации, особенно, не получив привязки.

Другим решением было бы иметь класс, полученный из QAbstract * Model, который обертывает данные, а также имеет эти функции преобразования и утилит. Затем они могли вызвать функции dataChanged и т. Д. Тогда я мог бы использовать этот класс также в бэкэнде. Но это будет хороший дизайн, или если бэкэнд не будет содержать классы QAbstract * Model?

Поскольку я нахожу это довольно трудно выразить мою проблему четко, я надеюсь, что мой вопрос понятно в некотором роде :-)

Answer 1

Это классический MVC вопрос, так что да, Модели, принадлежащие к серверной, даже объекты, основанные на QAbstractProxy. Это позволит легко масштабировать, быстрее реагировать и т. Д.

Конечно, если мы говорим о достаточно больших системах. Для маленьких, не имеющих планов для дальнейшего расширения, в MVC вообще нет ощущения.

Answer 2

В 100% -ном чистом дизайне у меня бы были классы моделей, не зависящие от модели Qt model/view, а затем создать над ним QAbstractItemModel. Это будет модель Model-View-ViewModel, а не классический MVC.

Я думаю, что это хороший дизайн, потому что QAbstractItemModel много разбирается с презентацией - такие вещи, как номера столбцов или роли отображения. Если они сохранены отдельно от модели, вы можете изменить презентацию, не касаясь модели вообще, и модель может быть меньше или даже реализована в стандартном C++.

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