Какую структуру программы вы делаете при использовании QML?

[xintrea]

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

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

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

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

[navrocky]

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

View <-> Presenter -> Model -> Repository

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

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

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

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

[NoIdea]

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

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

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

[AkonResumed]

Presenter - связующее звено между вьюхой и моделью, формирует данные для вьюхи, получаемые из модели. Реализует всю UI логику вьюхи и навигацию.  Его можно реализовывать и в QML и на плюсах, по вкусу.

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

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

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

Код:

Dialog {
    required property Week week  // класс бизнес логики
    ...
}

Создаю, соответственно, динамически

Код:

            var component = Qt.createComponent("WeekInfoDialog.qml")
            var object = component.createObject(appWindow, {week: currentWeek})

Но я только начал использовать QML.