Russian Qt Forum

Я разрабатывал всего две более-менее крупных программы на QML. Оба раза использовал такой подход: C++ - главный код, QML - как вспомогательный, только для отображения интерфейса.

Это выражалось в том, что, например, C++ оповещал QML об измнении отображаемых в интерфейсе значений через сигналы. Не QML запрашивал изменения значений, не классы регистрировались с Q_INVOKABLE, чтоб значения в QML сами менялись, а именно C++ код за всем следил.

И вот думаю, что надо отходить от такой структуры. А новую до конца все никак придумать не могу.

В связи с чем вопрос: кто как строит свои проекты с использованием QML?

Мне видится такая структура:

View <-> Presenter -> Model -> Repository

В этой схеме:
View - это интерфейс на QML,
Presenter - связующее звено между вьюхой и моделью, формирует данные для вьюхи, получаемые из модели. Реализует всю UI логику вьюхи и навигацию.  Его можно реализовывать и в QML и на плюсах, по вкусу.
Model - это некие сервисы и объекты данных, реализующие логику приложения без привязки к пользовательскому сценарию. Сервисы получают данные через репозитории, абстрагируясь от конкретных реализаций.
Repository - это конкретные источники внешних данных (сетевые запросы, БД, QSettings, файлы)

В этой схеме главным должен быть Presenter, остальные его подчиненные.

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

Все вот думаю запилить демо приложение, реализующее такую архитектуру, но руки не доходят.

При создании интерфейса на QtQuick делал упор на то чтобы каждый элемент и каждое окно отображались и работали отдельно от программы, т.е. можно запустить весь интерфейс или отдельный элемент через qmlscene и проверить его работу.

Модели данных и объекты подхватываются и создаются динамически через qml-синглтон из директории dummydata, в котором находятся qml-файлы имитирующие модели и объекты C++, которые в коде программы реализованы в виде отдельных классов (QObject) с набором свойств, данных и методов, сигналов/слотов если надо.

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

Presenter  должен быть на плюсах, ибо он один для разных видов. Например, QML и консольный интерфейс.

Очень стояще! Делаю примерно также, только всегда подаю на вход вида модель или класс бизнес-логики. Сразу видно от чего зависит вид.
Создаю, соответственно, динамически
Но я только начал использовать QML.