QUndoCommands是否应该绑定到视图或模型？

Question

在Qt的undo framework中，您可以拥有一堆QUndoCommand个实例。其中每个都描述了用户界面中的操作。在我们的应用程序中，我们有一组视图处理一组模型，一些组合在一起，我们经常有多个视图在同一组模型上工作。我现在正在研究基于此框架撤消操作的能力。

现在，我熟悉使用命令类来描述UI操作的一般模式，但这些模式应该表示UI元素中的状态更改，还是底层模型中的数据更改？一个命令类应该包含多少数据和状态？

一个例子来说明我的观点：假设你有一个QStandardItemModel作为基本模型，并且有许多代理模型。每个代理模型都会对各种类型进行转换，例如按特定值的出现进行过滤。然后，如果我创建一个命令类来专门更改其中一个代理模型中的一个值，并且过滤条件发生变化，那么该命令类的状态将变为无效。所以我必须包括过滤器的状态，或者映射到最终的底层模型。另一种选择是为UI中的所有状态更改添加命令（例如，导致过滤条件发生变化的命令），但这样做的缺点似乎是要撤消的命令列表变得相当大。

这里的最佳做法是什么？

Answer 1

这在某种程度上取决于您的应用程序及其使用方式，但以下是我过去用于撤消命令的一般准则：

• 是数据的一部分吗？如果是这样，用户应该可以撤消它。
• 以某种方式保存（在应用程序会话之间记住）？如果是这样，用户应该可以撤消它。
• 是否与该计划的主要目的有关？如果是这样，可撤消。
• 这是工作流程中经常完成的部分吗？如果是这样，可能会撤消。
• 是否根据其他变化触发？如果是这样，它应该在其他项目更改时撤消，而不是单独撤消。
• 每次* X *发生时都重置吗？你可能能够逃脱它不在撤销堆栈中。
• 是否可以通过相同的动作轻松撤消（例如隐藏/显示额外信息）？你可能不希望它在撤销堆栈中。

基于此以及您编写的内容，如果过滤经常发生和/或无法轻易更改，我可能会将撤消信息绑定到模型（数据）和视图。如果过滤很简单（基本子字符串过滤，如搜索您的电子邮件主题行），那么它可能不需要成为撤消状态的一部分，然后撤消命令只会绑定到数据。