如何实现QListView与QTableView共享模型联动及数据编辑增删？

一、优先用代理模型（无需重构现有UI） #

如果你的界面已经固定了QListView+QTableView的结构，完全没必要改用QTreeView，用QSortFilterProxyModel就能完美满足需求，甚至轻量的QIdentityProxyModel也能凑合用，但前者灵活性更强。

具体实现步骤：

• 给QListView绑定一个展示request_group的模型（比如QStandardItemModel或自定义QAbstractListModel），监听其selectionChanged信号捕获选中的组。
• 给QTableView配置QSortFilterProxyModel，将包含所有requestItem的数据源模型设为代理的sourceModel（数据源模型要能关联request_group和requestItem，比如每个requestItem带groupID标识）。
• 当QListView选中某个group时，重写代理模型的filterAcceptsRow方法，设置过滤规则只保留当前选中组对应的requestItem。
• 编辑、添加、删除操作直接在代理模型上执行——代理会自动同步操作到sourceModel，只要你的sourceModel和Suite数据双向绑定（比如sourceModel的dataChanged信号同步到Suite，或者sourceModel直接封装Suite的数据结构），就能自动更新Suite中的数据。

优势：

• 保留现有UI布局，不用重构界面
• 代理模型的过滤逻辑成熟，代码量小
• 编辑同步逻辑直接通过sourceModel与Suite的关联实现，无需额外处理层级操作

二、改用QTreeView的适用场景 #

只有当你需要在同一个视图内同时展示request_group和对应的requestItem（支持层级展开/折叠），或者未来有多层级分组的扩展需求时，才考虑切换到QTreeView。

若用QTreeView：

• 需实现自定义QAbstractItemModel，将request_group作为顶层节点，requestItem作为子节点
• 编辑、添加、删除操作要处理节点层级关系，比如添加requestItem时需指定父节点为当前选中的group
• 这种方案会彻底改变原双视图布局，需要重新设计UI结构

总结 #

如果当前界面已经确定是QListView+QTableView的结构，优先选择QSortFilterProxyModel，实现成本低，完全覆盖你的需求。仅当需要整合视图为树形层级结构时，再考虑QTreeView。

内容的提问来源于stack exchange，提问作者Chweng Mega