Sup*_*hne 3 model-view-controller design-patterns controller facade object-oriented-analysis
我的问题很简单.今天,前端和后端都有很多框架,它们实现了MVC(模型 - 视图 - 控制)架构.
"MVC中的控制器"是Facade Design Pattern的一个例子吗？
好吧,让我先说一下:我不认为术语"MVC"或"Facade"的定义不足以使这个问题简明扼要地回答.MVC有许多不同的"风味",每种都具有不同的属性.所以说清楚"是"或"不"我认为有点自以为是,但也没有那么有用.
我不相信Facade和Controller是一回事.
如果你看一下Gang-Of-Four设计模式,我们不能只通过代码结构来确定模式的含义或实现.意思是,你不能看大多数代码并说"这显然是一个X模式".
一个简单的例子是Facade和Adapter.从代码的角度来看,两者都是相同的,所以差异不是技术上的,而是你如何使用它.您构建了一个适配器,通过定义的API(接口)将一个复杂系统连接到另一个系统.在为同一目的创建新界面时,可以构建外观.这意味着区别在于新构建的层是满足现有接口(适配器)还是创建新接口(Facade).一旦写完,就没有区别了.
我们可以对Decorator和Proxy说同样的话.事实上,我们可以为很多人这样做.我在Beyond Design Patterns的上半部分基于此博客文章的同名谈论了这个事实.
最后,我们需要查看为什么编写代码以查看控制器和外观是否相同(或类似).
为什么要编写外观:因为您希望提供对复杂系统的更简单访问,通常用于特定用例.来自Sourcemaking:
为子系统中的一组接口提供统一接口.Facade定义了一个更高级别的接口,使子系统更易于使用.
为什么要编写控制器:因为您想为"外部用户"提供特定的功能.控制器将请求路由到您的"模型"并与视图交互.
什么是相同的(将简单的界面路由到幕后更复杂的集合).应用程序中的控制器就像Facade一样,它充当了针对特定用例的更复杂应用程序的"网关".
我认为这个问题非常有趣,因为它让我们思考为什么远不止于什么.如果你查看一个控制器作为一个通用的抽象,您可以从多个地方(在一个情况下,另一名来自HTTP,来自CLI)调用,那么它的确开始看起来LOT像一个门面.
但是,如果您的控制器倾向于在单个上下文中使用,那么它们就会像Facades一样停止查看,而是开始看起来就像通用代码一样.
这里的细微差别非常重要.事实上,对我而言,仅仅提出问题并思考细微差别是FAR比任何答案都重要.