简单表单的惯用 QT 架构？

Question

我目前正在从事一个需要使用许多类似表单的对话框的中型项目。我正在使用 Qt5 小部件开发此应用程序。 （我正在尝试为基于类的网络协议实现调试工具）。表单背后的大部分逻辑都很简单。

表单的视图如下所示：

基本上，当按下发送时，它只是使用表单中的数据构造一个数据包，并将其插入到消息缓冲区中，以便稍后在程序中适当时发送出去。我想在开发这个时使用正确的编码习惯，因为我正在使用这个项目来熟悉 GUI 编程。

让我担心的是，我不知道如何以一种可扩展、可测试和健壮的方式以惯用的方式构建我的代码。我不希望我的对话框直接负责将数据插入到发送流中，也不应该处理与之相关的任何业务逻辑。

我天真地认为视图应该只做很少的逻辑，而不是与用户编辑某些内容或按下按钮的过程的其他部分进行通信，也许它可以验证文本的格式是否正确。该过程的另一部分将是我想象的“模型”，因此（我相信）遵循 MV 架构。这导致了几个问题：

1. 像this 这样的大多数教程似乎都希望用户实现QAbstractListModel 或QAbstractTableModel，甚至可能是QAbstractItemModel，但这些似乎都不需要或与我正在处理的数据类型无关此外，对于我认为简单的数据流，他们的接口似乎非常笨拙——我是否需要继承其中一个以正确实现 MV 架构，还是我可以自己管理连接？如果我自己管理连接，我应该创建一个演示者类来处理这个问题并因此实现 MVP 架构吗？
2. 应如何将数据从该表单传递到应用程序的其余部分？如果合理/正确，我宁愿避免任何/所有全局/静态设计。在发送时，应该构建一个数据包并将其插入发送缓冲区，但是应该在这个对话框的模型中完成吗？该模型是否应该提供对缓冲区或其控制接口的引用并对其进行操作？是否应该将相关数据传递或返回到处理缓冲区操作的外部模型？
3. 这些形式中的数据基本上是1对1的，其中包含构造发送缓冲区消息所需的信息，以至于您可以合理地使用或调整现有接口成为功能模型，但是，我觉得这将是一种代码气味——对吗？我是否应该创建一个基本上反映我的消息类的新类，以便更好地分离关注点？

感谢大家提供的任何见解或资源。这在很大程度上是我对问题的过度思考，但我想在实现 60 多个对话框之前确保我的设计理念是合理的，以便此应用程序可以完全覆盖协议的标准。

Answer 1

我不希望我的对话框直接负责将数据插入发送流

没错。它应该只负责将数据传递给负责发送消息的某个服务，即关注点分离和单一职责。

像这样的大多数教程似乎都希望用户实现 QAbstractListModel 或 QAbstractTableModel，甚至可能是 QAbstractItemModel，但这些似乎都不需要或与我正在使用的数据类型无关，

您的数据是否将在表格/列表/树中表示。如果是，那么您可以使用其中之一/子类化它们。或者，您可以使用不使用模型视图设计的QListWidget / QTreeWidget 等。如果不是，那么这些显然不适合您。这取决于数据以及您希望如何呈现数据，并且只有您知道数据，因此您必须做出决定。

应该如何将数据从这个表单传递到应用程序的其余部分？

使用信号/槽机制。以图中的表格为例。上面的send 按钮不应该发送任何东西。它应该只接受输入到表单中的数据，然后通过信号将该数据传递给其他一些服务，例如 MessageSender 服务或 ValidationService。这就是表单应该做的所有事情。

如果合理/正确，我宁愿避免任何/所有全局/静态设计。

这很好，除非没有其他办法，否则您应该避免使用它们。例如，日志服务是在程序的整个生命周期中在程序中到处都需要的东西，我会将其设为单例。

在发送时，应该构建一个数据包并将其插入发送缓冲区，但是否应该在此对话框的模型中完成？该模型是否应该提供对缓冲区或其控制接口的引用并对其进行操作？

使用信号/插槽。对话框应该只接受输入，它不应该发送数据或做其他事情。它应该接受输入并将其传递。考虑到这一点来设计您的类/对象。