我的问题很简单。今天，前端和后端都有很多框架，它们实现了MVC（模型 - 视图 - 控制）架构。
MVC中的'控制器'是外观设计模式的一个示例吗？
答案 0 :(得分：7)
好的，让我先说一下：我不会想到这些条款＆＃34; MVC＆＃34;也不是＆＃34; Facade＆＃34;定义得足以使这个问题简明扼要地回答。有许多不同的口味＆＃34;每个MVC都有不同的属性。所以说清楚＆＃34;是＆＃34;或＆＃34;不＆＃34;我认为有点自以为是，但也没有那么有用。
我不相信Facade和Controller是一回事。
如果你看一下Gang-Of-Four设计模式，我们就不能通过代码结构来确定模式的含义或实现。这意味着，您无法查看大多数代码并说出＆＃34;这显然是一个X模式＆＃34;。
一个简单的示例是Facade和Adapter。从代码的角度来看，两者都是相同的，所以差异不是技术性的，而是你如何使用它。您构建了一个适配器，通过定义的API（接口）将一个复杂系统连接到另一个系统。当您为同一目的创建新界面时，您可以构建一个外观。这意味着区别在于新构建的层是满足现有接口（适配器）还是创建新接口（Facade）。一旦写完，就没有区别了。
我们可以对Decorator和Proxy说同样的话。事实上，我们可以为很多人这样做。我在演讲的前半部分Beyond Design Patterns基于此Blog Post by the same name来讨论这个事实。
最终，我们需要查看为什么编写代码以查看控制器和外观是否相同（或相似）。
为什么要编写外观：因为您希望提供对复杂系统的更简单访问，通常是针对特定用例。来自Sourcemaking：
为子系统中的一组接口提供统一接口。 Facade定义了一个更高级别的界面，使子系统更易于使用。
为什么要编写一个控制器：因为你想为一个＆＃34;外部用户＆＃34;提供一个特定的功能。控制器将请求路由到您的＆＃34;模型＆＃34;并与View进行交互。
相同（将简单界面路由到幕后更复杂的集合）。应用程序中的控制器就像Facade一样，它充当了一个＆＃34;网关＆＃34;针对特定用例的更复杂的应用程序。
我认为这个问题非常有趣，因为它让我们思考为什么远不止于什么。如果您将控制器视为可以从多个位置调用的通用抽象（在一种情况下从HTTP调用，在另一种情况下从CLI调用），那么它确实开始像Facade一样看起来像 LOT 。
但是，如果您的控制器倾向于在单个上下文中使用，那么它们就像Facades一样停止查看，而是开始看起来就像通用代码一样。
这里的细微差别非常重要。事实上，对我来说，只是提出问题并思考细微差别 FAR 比任何答案都重要。
答案 1 :(得分：1)
正如@ircmaxell指出的那样，在回答一个定义不明确的问题时会遇到麻烦。
为了清楚起见，我会使用Fowler's definition of an MVC Controller（强调我的）：
MVC的演示部分由剩下的两个元素组成：view和 controller 。 控制器的作业是获取用户的输入并弄清楚如何处理它。
此时我要强调的是，不仅有一个视图和控制器，您对屏幕的每个元素都有一个view- controller 对，每个控件和屏幕作为一个整体。
我将使用有关Facade的 intent 的文本（来自我的GoF副本）：
意图
为子系统中的一组接口提供统一接口。 Facade定义了一个更高级别的界面，使子系统更易于使用。
根据这些定义，它们并不是一回事。
现在，值得一提的是 GRASP Controller （不是MVC）通常是应用程序或域层的外观：
名称：控制器 问题：UI层之外的第一个对象是否接收并协调（＆＃34;控制＆＃34;）系统操作？ 解决方案：将责任分配给表示以下选项之一的对象：
- 表示整个“系统”，“根对象”，软件在其中运行的设备，或主要子系统（这些都是外观控制器的变体）。
- 表示发生系统操作的用例场景（用例或会话控制器）