简单形式的惯用 QT 架构？
Idomatic QT architecture for simple forms?
我目前正在从事一个中型项目，该项目需要使用许多类似表单的对话框。我正在使用 Qt5 小部件开发此应用程序。 （我正在尝试为基于 class 的网络协议实现调试工具）。表格背后的大部分逻辑都非常简单。
表单的视图如下所示：
基本上，当按下发送时，它只是使用表单中的数据构造一个数据包，并将其插入到消息缓冲区中，以便在程序稍后适当的时候发送出去。我想在开发这个项目时使用适当的编码惯用语，因为我正在使用这个项目来熟悉 GUI 编程。
我担心的是，我不知道如何以可扩展、可测试和健壮的方式惯用地构建我的代码。我不希望我的对话框直接负责将数据插入发送流，也不应该处理与之关联的任何业务逻辑。
我天真地认为，视图应该做很少的逻辑，而不是与流程的其他部分进行通信，告知用户已经编辑了某些内容或按下了按钮，也许它可以验证文本的格式是否正确.该过程的另一部分将是我想象的 'model'，因此（我相信）遵循 MV 架构。这导致了几个问题：
- 像 this 这样的大多数教程似乎希望用户实现
QAbstractListModel 或 QAbstractTableModel，甚至 QAbstractItemModel，但是 none其中一些似乎需要或与我正在使用的数据类型相关，此外，它们的界面对于我认为简单的数据流来说似乎非常笨拙——我需要子class其中之一吗为了正确地实现 MV 架构，还是我可以自己管理连接？如果我自己管理连接，我是否应该创建一个演示者 class 来处理这个问题并因此实现 MVP 架构？
- 应如何将数据从此表单传递到应用程序的其余部分？如果 plausible/correct，我宁愿避免 any/all global/static 设计。在发送时，应该构造一个数据包并将其插入发送缓冲区，但是应该在这个对话的模型中完成吗？该模型是否应该提供和操作对缓冲区或其控制接口的引用？是否应该将相关数据传递或返回到某个可以处理缓冲区操作的外部模型？
- 这些形式的数据基本上与构造发送缓冲区消息所需的信息是一对一的，以至于您可以合理地使用或将现有接口改编为功能模型，但是，我感觉这会是一种代码味道——对吗？我是否应该创建一个基本上反映我的消息 class 的新 class 以便更好地分离关注点？
感谢大家提供的任何见解或资源。这大部分是我想多了，但我想在我实现 60 多个对话框之前确保我的设计理念是正确的，这样这个应用程序才能完全涵盖协议的标准。
I don't want my dialog to be directly responsible for inserting the data into the send stream
没错。它应该只负责将数据传递给负责发送消息的某些服务，即关注分离和单一责任。
Most tutorials like this seem to want the user to implement a QAbstractListModel or a QAbstractTableModel, or perhaps even a QAbstractItemModel, but none of these seem needed or relevant to the type of data I am working with,
您的数据是否会在 table/列表/树中表示。如果是，那么您可以使用其中之一/将它们子类化。或者，您可以使用不使用模型视图设计的 QListWidget / QTreeWidget 等。如果不是，那么这些显然不适合您。这取决于数据以及您希望如何呈现数据，只有您知道数据，因此您必须做出决定。
How should data be passed from this form to the rest of the application?
使用信号/槽机制。以图中的表格为例。上面的 send 按钮不应发送任何内容。它应该只接受输入到表单中的数据，然后通过信号将该数据传递给其他一些服务，例如 MessageSender 服务或 ValidationService。这就是表格应该做的。
I would prefer to avoid any/all global/static designs if plausible/correct.
这很好，除非没有其他办法，否则您应该避免使用它们。例如，日志服务是在程序的整个生命周期中在程序中随处需要的东西，我会把它做成单例。
On send a packet should be constructed and inserted into the send buffer, but should that be done in the model for this dialog? Should a reference to the buffer or its controlling interface be provided and manipulated by this model?
使用信号/槽。对话框应该只是接受输入，它不应该四处发送数据或做其他事情。它应该接受输入并将其传递下去。设计您的 类 / 对象时要牢记这一点。
我目前正在从事一个中型项目，该项目需要使用许多类似表单的对话框。我正在使用 Qt5 小部件开发此应用程序。 （我正在尝试为基于 class 的网络协议实现调试工具）。表格背后的大部分逻辑都非常简单。
表单的视图如下所示：
基本上，当按下发送时，它只是使用表单中的数据构造一个数据包，并将其插入到消息缓冲区中，以便在程序稍后适当的时候发送出去。我想在开发这个项目时使用适当的编码惯用语，因为我正在使用这个项目来熟悉 GUI 编程。
我担心的是，我不知道如何以可扩展、可测试和健壮的方式惯用地构建我的代码。我不希望我的对话框直接负责将数据插入发送流，也不应该处理与之关联的任何业务逻辑。
我天真地认为，视图应该做很少的逻辑，而不是与流程的其他部分进行通信，告知用户已经编辑了某些内容或按下了按钮，也许它可以验证文本的格式是否正确.该过程的另一部分将是我想象的 'model'，因此（我相信）遵循 MV 架构。这导致了几个问题：
- 像 this 这样的大多数教程似乎希望用户实现
QAbstractListModel或QAbstractTableModel，甚至QAbstractItemModel，但是 none其中一些似乎需要或与我正在使用的数据类型相关，此外，它们的界面对于我认为简单的数据流来说似乎非常笨拙——我需要子class其中之一吗为了正确地实现 MV 架构，还是我可以自己管理连接？如果我自己管理连接，我是否应该创建一个演示者 class 来处理这个问题并因此实现 MVP 架构？ - 应如何将数据从此表单传递到应用程序的其余部分？如果 plausible/correct，我宁愿避免 any/all global/static 设计。在发送时，应该构造一个数据包并将其插入发送缓冲区，但是应该在这个对话的模型中完成吗？该模型是否应该提供和操作对缓冲区或其控制接口的引用？是否应该将相关数据传递或返回到某个可以处理缓冲区操作的外部模型？
- 这些形式的数据基本上与构造发送缓冲区消息所需的信息是一对一的，以至于您可以合理地使用或将现有接口改编为功能模型，但是，我感觉这会是一种代码味道——对吗？我是否应该创建一个基本上反映我的消息 class 的新 class 以便更好地分离关注点？
感谢大家提供的任何见解或资源。这大部分是我想多了，但我想在我实现 60 多个对话框之前确保我的设计理念是正确的，这样这个应用程序才能完全涵盖协议的标准。
I don't want my dialog to be directly responsible for inserting the data into the send stream
没错。它应该只负责将数据传递给负责发送消息的某些服务，即关注分离和单一责任。
Most tutorials like this seem to want the user to implement a QAbstractListModel or a QAbstractTableModel, or perhaps even a QAbstractItemModel, but none of these seem needed or relevant to the type of data I am working with,
您的数据是否会在 table/列表/树中表示。如果是，那么您可以使用其中之一/将它们子类化。或者，您可以使用不使用模型视图设计的 QListWidget / QTreeWidget 等。如果不是，那么这些显然不适合您。这取决于数据以及您希望如何呈现数据，只有您知道数据，因此您必须做出决定。
How should data be passed from this form to the rest of the application?
使用信号/槽机制。以图中的表格为例。上面的 send 按钮不应发送任何内容。它应该只接受输入到表单中的数据，然后通过信号将该数据传递给其他一些服务，例如 MessageSender 服务或 ValidationService。这就是表格应该做的。
I would prefer to avoid any/all global/static designs if plausible/correct.
这很好，除非没有其他办法，否则您应该避免使用它们。例如，日志服务是在程序的整个生命周期中在程序中随处需要的东西，我会把它做成单例。
On send a packet should be constructed and inserted into the send buffer, but should that be done in the model for this dialog? Should a reference to the buffer or its controlling interface be provided and manipulated by this model?
使用信号/槽。对话框应该只是接受输入，它不应该四处发送数据或做其他事情。它应该接受输入并将其传递下去。设计您的 类 / 对象时要牢记这一点。