c++ - 在 C++ 桌面应用程序的上下文中使用 MVC 的导航/ View 流

Question

假设您有一个全屏 C++ 桌面应用程序，它由多个屏幕组成，每个屏幕都有不同的功能，还有一个具有适当模型的 ViewController。例如以下一组非常简化的屏幕:

1. 测验:用户通过一组多项选择题进行导航。
2. 统计测验结果。
3. 信息:向用户显示有关特定主题的信息。
4. 菜单(测验、信息、退出)

根据 GRASP 原则 Information Expert 判断，每个 ViewController 最清楚何时完成以及何时移动到新屏幕。然而，根据同样的原则，它不是决定下一个屏幕实际应该是什么的正确位置。在这个相当简单的例子中，人们可能会争辩说这没问题，但在更复杂的应用程序中，它无疑会导致重复的代码和逻辑以及更高的耦合和更低的内聚性。还有一个问题是，您必须在当前屏幕的 ViewController 中创建新的小部件和 Controller ，这会带来各种新问题，至少根据 Creator 原则，这不是正确的选择。您将不得不引入一个工厂来缓解其中的一些问题。

因此，下一个合乎逻辑的步骤是引入一个 ApplicationController，它唯一负责管理 View 及其 Controller ，包括从一个 View 到下一个 View 的导航流。

在我看来，这仍然存在一个悬而未决的问题:如何向 ApplicationController 发出信号，表明是时候移动到另一个屏幕并将控制权正确地移交给该对象了？

例如，可以使用观察者模式。然而，如果您现在有一个昂贵的 View 处于事件状态，并且希望在新屏幕处于事件状态时销毁该 View 怎么办？如果当前的 ViewController 向 ApplicationController 发出下一个屏幕应该打开的信号，它可以管理所有事情，直到它会破坏当前事件的屏幕，这是它做不到的，因为当前调用恰好来自该对象。除了该方法的其他几个问题。

所以我的问题是(对于所有冗长的介绍感到抱歉 :P):如何使用 MVC 正确地实现从一个全屏小部件到另一个全屏小部件的导航流，它解决了上述问题，在 View-和 ApplicationController，并且在耦合和内聚方面很好地面向对象？

Answer 1

有时您会在思考过程中遗漏一个细节，然后打开一大堆问题，甚至都没有意识到自己犯了错误。

在这种情况下，细节是您可以自然地发布异步和同步事件。如果您必须确保您不再处于事件发布方法的上下文中，请发布一个异步事件。一旦您在处理程序中收到该事件，您就可以确定上下文已保留。例如，如果您愿意，您可以安全地删除该对象。自然地，事件处理程序不应位于您尝试删除的同一对象的上下文中。

为了完整性:在 Qt 中，您可以为使用 connect() 建立的每个信号/槽连接指定它应该是 Qt::QueuedConnection 类型。如果你发出一个信号，它不会被传递，直到控制返回到线程的事件循环。通常，如果接收器在同一个线程中，则使用 Qt::AutoConnection 在它被引发时传递一个信号(Qt::DirectConnection)，或者如果接收器在一个不同的线程。

在 wxWidgets 中，您可以使用 wxEvtHandler::QueueEvent(wxEvent* event) 对事件进行排队，例如，它可以通过应用程序单例获得。