有了前面诸多设计模式的基础，这儿可以提出一个比较特殊的模式MVC。MVC并不属于GOF 的23个设计模式之列，但是它在GOF的书中作为一个重要的例子被提出来，并给予了很高的评 价。一般的来讲，我们认为GOF的23个模式是一些中级的模式，在它下面还可以抽象出一些更 为一般的低层的模式，在其上也可以通过组合来得到一些高级的模式。MVC就可以看作是一些 模式进行组合之后的结果（实际上，MVC的出现要早于设计模式的提出，这而只是对它在设计 模式的基础上进行在分析）。如果没有前面的基础，理解MVC或许会有一些困难。
MVC模式
MVC模式比较的特别，它含义比较的广，涉及的层面也不仅仅是设计这一块，不好简单的 把它归为设计模式。当然，它主要还是作为一个设计的概念被提到的，而且在Java体系中， MVC有着至关重要的作用。这儿提的是Java中的设计模式，当然不好拉了它不讲了。
关于MVC的来龙去脉，这儿就不再讲了。这里主s要讲两个方面的：作为设计模式的MVC和 作为体系结构模式的MVC。
所谓MVC，指的是一种划分系统功能的方法，它将一个系统划分为三个部分：
模型（Model）：封装的是数据源和所有基于对这些数据的操作。在一个组件中，Model往 往表示组件的状态和操作状态的方法。
视图（View）：封装的是对数据源Model的一种显示。一个模型可以由多个视图，而一个 视图理论上也可以同不同的模型关联起来。
控制器（Control）：封装的是外界作用于模型的操作。通常，这些操作会转发到模型上 ，并调用模型中相应的一个或者多个方法。一般Controller在Model和View之间起到了沟通的 作用，处理用户在View上的输入，并转发给Model。这样Model和View两者之间可以做到松散 耦合，甚至可以彼此不知道对方，而由Controller连接起这两个部分。
有了前面介绍的诸多模式之后，就可以很容易的通过模式来解释MVC的内在行为了。前面 说过，在设计模式中，MVC实际上是一个比较高层的模式，它由多个更基本的设计模式组合而 成，Model-View的关系实际上是Observer模式，模型的状态和试图的显示相互响应，而View -Controller则是由Strategy模式所描叙的，View用一个特定的Controller的实例来实现一个 特定的响应策略，更换不同的Controller，可以改变View对用户输入的响应。而其它的一些 设计模式也很容易组合到这个体系中。比如，通过Composite模式，可以将多个View嵌套组合 起来；通过FactoryMethod模式来指定View的Controller，等等。
使用MVC的好处，一方面，分离数据和其表示，使得添加或者删除一个用户视图变得很容 易，甚至可以在程序执行时动态的进行。Model和View能够单独的开发，增加了程序了可维护 性，可扩展性，并使测试变得更为容易。另一方面，将控制逻辑和表现界面分离，允许程序 能够在运行时根据工作流，用户习惯或者模型状态来动态选择不同的用户界面。
Swing号称是完全按照MVC的思路来进行设计的。在设计开始前，Swing的希望能够达到的 目标就包括：
模型驱动（Model-Driven）的编程方式。
提供一套单一的API，但是能够支持多种视感（look-and-feel），为用户提供不同的界面 。
很自然的可以发现，使用MVC模式能够有助于实现上面的这两个目标。
严格的说，Swing中的MVC实际上是MVC的一个变体：M-VC。 Swing中只显示的定义了Model 接口，而在一个UI对象中集成了视图和控制器的部分机制。View和Control比较松散的交叉组 合在一起，而更多的控制逻辑是在事件监听者部分引入的。
但是，这并没有妨碍在Swing中体现MVC的精髓。事实上，在Swing的开发初期，Swing确实 是按照标准的MVC模式来设计的，但是很快的问题就出现了：View和Controller实际上是紧密 耦合的，很难作出一个能够适应不同View的一般化的Controller来，而且，一般也没有很大 的必要。