我已经处理了一段时间，但似乎无法确定这个困境的具体答案。我一直在构建这个围绕MVC风格模式组织的GUI程序，我遇到了以下问题：如果熟悉这个体系结构模式；控制器"；对象应该处理由"；视图"；对象(向用户呈现GUI的东西(，这些对象来自用户输入，例如按钮单击。
然而，在某些情况下，对单击按钮的响应可能涉及到需要在其中显示另一个视图，例如对话框或窗口中的窗格，这取决于GUI的布局。但当这样做的时候；逻辑"；对我来说，控制器不应该担心GUI的布局，只需要设置这样的视图。也就是说，视图有上下文，并且嵌套在一起，我们希望控制器不必知道上下文和嵌套。
那么，诀窍是如何最好地实现这种孤立——或者知道它是否真的是"孤立"；糟糕的设计"；不要把它放在那里，因为最简单、最明显的解决方案是忘记它，在控制器中创建视图，控制器必须知道上下文，如果我们重新排列GUI，就必须更改上下文。但这似乎违背了"；单一责任原则；面向对象编程(该程序使用(。它给控制器提供了更多的"；改变的理由"；。如果可以避免的话，这显然不是理想的。
我提出的另一种选择是使用"；视图管理器"；它可以完全控制视图的创建，它了解所有上下文。但即使在这里，似乎也有更微妙的知识泄漏，因为"哪个视图与哪个包含视图"对应"；在存在多个可用的包含视图的情况下，可能会变得不明确。如果控制器要求子视图，而不是父视图(对此一无所知，还记得吗，如果控制器是在假设它会得到一个单独的视图供自己使用的情况下设计的，那么它就有可能在控制器之间产生微妙的串扰。
这个问题还有更优雅的答案吗？
简短的回答：简单地说，你没有。稍微长一点的答案：MVC是一种表示模式。这意味着它有助于处理应用程序的演示层。
不要被"；控制器"：它们不是用来处理业务逻辑的，而是用来将UI调用转发到适当的服务。控制器必须是"；薄"；，只是简单的代理(或者，在极端情况下，从DTO/ViewModels映射到适当的业务模型(。
确保所有的基础都被封装并抽象到一个与UI无关的层中。