WPF 下的 MVVM 与 QT 的 MVP 比较

b站来源：《深入浅出WPF》
首先讲了WPF 的基本配置，然后

从容易变化的view 角度看

• MVP：
  p是委托，和view 高频率交互

• MVVM：
  view 和 viewmodel 高频率交互

QT

Qt自然具有模型视图 来管理数据及其表示。一些人认为，Qt滥用了模型视图术语 ，因此更正确的命名是

数据->模型
型号-> ViewModel
委托->控制器
查看（可以）
不管使用哪种正确的术语，Qt都不会对复杂应用程序的体系结构，如何构建Data以及将业务逻辑放置在何处进行详细说明。Qt的模型视图是一种使用户数据适应Qt的树和表并通过委托调整其行为的方法。

给定库是试图了解如何处理应用程序数据的尝试。

实现MVP 的方法，得用 QAbstractProxyModel，但是我又找到了这段话

在大型Qt应用程序中，业务逻辑很快就被表示逻辑所破坏。诸如Qt类之类的东西QModelIndex开始出现在任何地方，即使在与Qt图形无关的地方也是如此。尝试存储GUI会话数据QAbstractItemModel会导致Qt树和表的布局不灵活。尝试通过修复此问题QAbstractProxyModel 导致出现极为复杂的代理模型。从依赖关系中删除Qt可以使更多的精力集中在GUI应用程序的常见需求（即对象构建，属性编辑等）上，而不是在呈现细节上。

让我这个大作业（还用着古老的 MVC 的分层，从大二拖到现在的）突然没动力做了。。。想挖新坑了
然后就找了以下的东西

基于MVVM(Model-View-ViewModel)实现，一个短学期课程，3个同学合作，作为入门项目应该不错
这个看起来针不戳   别人造的轮子：QT 的 MVVM库，最近更新在2020/01

两者比较：
WPF：使用xaml来定义控件，完全学习了html的方式。控件之间可以任意组合，任意包含。

控件层之间的消息自然传递。（需要设计精良的布局层次）

QT：所有的控件元素全部继承自QWidget，而不是Object。因此得使用使用QLayout进行过渡。

connect操作直接决定了源和目的两个对象以及各自的触发和响应（给与绑定以充分的自由度）

嵌入式那边也有系统，不过留坑吧。。。