在 MVC 模式的 GUI 应用程序中，可以、应该以及如何最好地将控制器与 GUI 布局隔离？

Question

我一直在摆弄这个问题，但似乎无法解决这个困境的特定答案。我一直在构建这个围绕 MVC 样式模式组织的 GUI 程序，我遇到了以下问题：如果有人熟悉这种架构模式，那么“控制器”对象应该处理由来自用户输入的“视图”对象（将 GUI 呈现给用户的东西），例如按钮单击。

但是，在某些情况下，对单击按钮的响应可能需要在其中放置另一个视图，例如对话框或窗口中的窗格，具体取决于我们的 GUI 的布局方式。但是当这样做时，对我来说，控制器不应该担心 GUI 的布局似乎是“合乎逻辑的”，只需要放置这样的视图即可。也就是说，视图具有它们的上下文，并且嵌套在一起，我们希望控制器不必知道上下文和嵌套。

那么，诀窍是如何最好地实现这种隔离 - 或者知道没有它是否真的是“糟糕的设计”，因为最简单和最明显的解决方案就是忘记它，让在控制器中查看，并且控制器必须知道上下文，并且如果我们重新排列 GUI，则必须进行更改。但这似乎违背了诸如面向对象编程的“单一责任原则”（本程序使用）之类的原则。它给了控制器更多的“改变的理由”。这显然不是理想的如果可以避免。

我想出的替代方法是使用“视图管理器”，它可以完全控制视图的创建，它知道所有上下文。但即使在这里，似乎也存在更微妙的知识泄漏，因为在有多个包含视图可用的情况下，“哪个视图与哪个包含视图一起使用”可能会变得模棱两可。如果控制器请求子视图，而不是父视图（不知道，还记得吗？），那么视图管理器将在放置子视图的位置上进退两难，除非它以某种方式通知它，否则（如在当前程序中），视图管理器只允许一个视图，然后将相同的视图返回给控制器，如果控制器是在假设下设计的将获得一个单独的视图供自己使用。

有没有更优雅的答案？

Answer 1

简短的回答：简单地说，你不知道。 稍微长一点的答案：MVC 是一种 presentational 模式。这意味着它有助于处理应用程序的表示层。

不要对“控制器”这个词感到困惑：它们不是用来处理业务逻辑的，而是用来将 UI 调用转发到适当的服务。 控制器必须“瘦”，只是简单的代理（或者，在极端情况下，从 DTO/ViewModel 映射到正确的业务模型）。

确保所有基础工作都被封装并抽象到与 UI 无关的层中。