QML作为一种界面技术，灵活性和表现性是很赞的。特别是它支持js，也支持访问QObject对象的方式与c++进行交互的方式，个人认为非常的方便实用。

以上的这些特征，使QML可以很方便的作为一种纯粹的前端技术来使用。前端逻辑支持js编码，可以完全脱离后端运行，借助js对json数据的支持能力，可以非常方便的访问结构化的数据，数据处理能力不再成为问题，通过C++与程序的功能部分交互。

对于参数配置类的数据，可以通过QJsonObject直接组织为json格式对象，传给前端QML即可，大大简化了相关过程的处理。这种方式界面与应用是无关的，应用无需关心前端需要什么数据，只需要把相关的数据组织好，传给前端即可，至于前端如何使用，完全不必关心。

对于状态类的数据，只需要按照特定协议格式，将相关数据组织为json格式，剩余的操作，本质上跟参数操作是一致的，因为协议是一种稳定的状态，所以这种交互也会维持在一种稳定的状态，至于界面需求的变化，后端是完全不必关心的，除非必要，在协议内添加相关的数据项即可。

对于action类（参数保存，动作类）的写入或执行操作，不太适合使用统一的结构化文档方式来处理（或者说我暂时还没想到合适的结构来处理这类数据），暂时使用传统的function接口方式，每个数据或者动作提供一个function来处理，这种方式略显复杂，但只有这一种类型的数据使用这种方式还是可以接受的，更关键的是，这种类型的数据/动作 非常适合使用这种方式来处理。

还有一种很关键的数据，就是数据库的操作，暂时还没想到很合适的方式来处理，基本上数据库是一个单独的功能单元（不包含数据的自动录入，这是在其它功能单元内处理的，这里数据库的功能单元是面向界面的），最终的数据提供方式，也完全可以参照上述的设计来实现。

综上设计，可以很容易的实现一种前后端分离的程序结构，前端就是一个QML程序，可以通过传统的C++方式（dll或者lib）访问功能数据，或者通过rest webservice的方式访问功能数据均可。

而且借助QT强大的跨平台特性，可以很方便的生成兼容window，linux和嵌入式设备的程序。

以上架构，通过一个视频车流量检测的项目实践过，很实用，开发周期也短，非常适合项目实践。这不是一个大型项目的架构，适合开发功能相对单一但是组织完整的具体功能模块。