Design patterns 是一个'；控制器'；门面模式的一个例子？

我的问题很简单。今天，有很多前端和后端框架都实现了MVC（Model View Control）体系结构

---

“MVC中的控制器”是门面设计模式的一个例子吗？

好的，让我先说一句：我认为“MVC”和“门面”的定义不足以使这个问题得到简洁和绝对的回答。MVC有许多不同的“风格”，每种风格都有不同的属性。所以说清楚“是”或“不是”我觉得有点固执己见，但也不是很有用

一般答复 我不相信门面和控制器是一回事

如果你看一下四人组设计模式，我们不能仅仅通过代码结构来确定模式的意义或实现。也就是说，你不能看着大多数代码说“这显然是一个X模式”

一个简单的例子是一个Facade和一个适配器。从代码的角度来看，两者都是相同的，所以区别不是技术上的，而是如何使用它。您可以构建一个适配器，用定义的API（接口）将一个复杂系统连接到另一个复杂系统。在为相同目的创建新接口时，可以构建一个外观。这意味着新构建的层是满足现有接口（适配器）还是创建新接口（Facade）。一旦写好了，就没什么区别了

我们可以对Decorator和Proxy说同样的话。事实上，我们可以为许多人这样做。我在演讲的前半部分是根据这个来谈论这个事实的

为什么重要 最后，我们需要看看为什么要编写代码，看看控制器和外观是否相同（或相似）

为什么要编写facade：因为您希望提供对复杂系统的更简单访问，通常是针对特定用例。来自Sourcemaking：

为子系统中的一组接口提供统一接口。Facade定义了更高级别的接口，使子系统更易于使用

为什么要编写控制器：因为您希望向“外部用户”提供特定的功能。控制器将请求路由到“模型”并与视图交互

相同之处（将一个简单的接口路由到幕后更复杂的集合）。应用程序中的控制器的作用与Facade类似，因为对于特定用例，它充当更复杂应用程序的“网关”

细微差别 我认为这个问题真的很有趣，因为它让我们思考为什么远多于什么。如果将控制器视为可从多个位置调用的通用抽象（一种情况下从HTTP调用，另一种情况下从CLI调用），那么它确实开始看起来非常像一个外观

然而，如果您的控制器倾向于在单个上下文中使用，那么它们看起来就不再像外观，而是开始像普通代码一样

---

这里的细微差别非常重要。事实上，对我来说，简单地问这个问题并思考其中的细微差别远比任何答案都重要。

正如@ircmaxell所指出的，回答一个定义不明确的问题有困难

为了清楚起见，我将使用（强调我的）：

MVC的表示部分由剩下的两个元素组成：视图和控制器。控制器的工作是获取用户的输入，并确定如何处理它

在这一点上，我应该强调，不仅仅只有一个视图和控制器，屏幕的每个元素、每个控件和整个屏幕都有一个视图-控制器对

我将使用本文介绍Facade的意图（来自我的GoF副本）：

意图 为子系统中的一组接口提供统一接口。Facade定义了更高级别的接口，使子系统更易于使用

根据这些定义，它们不是一回事

现在，值得一提的是（不是MVC）通常是应用程序或域层的门面：

名称：控制器 问题：UI层之外的第一个对象接收并协调（“控制”）系统操作？ 解决方案：将责任分配给表示以下选项之一的对象：

• 表示整个“系统”、“根对象”、软件在其中运行的设备或主要子系统（这些都是facade控制器的变体）
• 表示发生系统操作的用例场景（用例或会话控制器）