Qt4 QUNDO命令应该绑定到视图还是模型？

在Qt中，您可以有一堆

QUndoCommand

实例。其中每一个都描述了用户界面中的一个操作。在我们的应用程序中，我们有一组视图处理一组模型，有些视图是组合的，并且我们经常有多个视图处理同一组模型。我现在正在研究基于此框架撤消操作的能力

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

举个例子来说明我的观点：假设您有一个

QStandardItemModel

作为基本模型，并且有许多代理模型位于此模型之上。每个代理模型都将进行排序转换，例如根据某个值的出现情况进行过滤。然后，如果我创建一个命令类来专门更改其中一个代理模型中的一个值，并且过滤器条件发生更改，则该命令类的状态将变为无效。因此，我还必须包括过滤器的状态，或者到最终底层模型的映射。另一个选项是为UI中的所有状态更改（例如，导致过滤器条件更改的更改）添加命令，但这样做的缺点似乎是要撤消的命令列表变得相当大

---

这里的最佳实践是什么？

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

• 这是数据的一部分吗？如果是这样，用户应该能够撤消它
• 是否以某种方式保存（在应用程序会话之间记住）？如果是这样，用户应该能够撤销它
• 这与课程的主要目的有关吗？如果是，可以撤销
• 这是工作流程中经常做的一部分吗？如果是这样的话，很可能是无法挽回的
• 它是基于其他变化而触发的吗？如果是这样的话，它应该在其他项重新更改时撤消，而不是自行撤消
• 是否每次发生*X*时都会重置？您可能可以避免它不在撤消堆栈中
• 通过同一个动作（例如隐藏/显示额外信息）是否容易撤消？您可能不希望它出现在撤消堆栈中

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