MVC设计模式

MVC设计模式
1 MVC介绍
众所周知MVC不是设计模式，是⼀个⽐设计模式更⼤⼀点的模式，称作设计模式不合理，应该说MVC它是⼀种软件开发架构模式，它包含了很多的设计模式，最为密切是以下三种：Observer (观察者模式), Composite（组合模式）和Strategy（策略模式）。

所以说MVC模式⼜称复合模式。

MVC(Model-View-Controller) 模式的基本思想是数据，显⽰和处理相分离。

模型(Model)负责数据管理，视图(View)负责数据显⽰，控制器(Controller)负责业务逻辑和响应策略。

从MVC的形成过程来看，最初只有模型和视图两个元素。

模型封装了数据并提供操作接⼝，视图⽤来表现数据和接收⽤户请求。

模型是独⽴的，⽽视图依赖于模型：从模型获取数据进⾏显⽰；向模型发送⽤户请求，并根据返回结果刷新⾃⼰。

需要⽤多个视图表现同⼀模型时，情况发⽣了变化：⼀个视图修改数据以后，不但本⾝要刷新，其他所有视图也要刷新。

如果由该视图通知其他视图，它就需要知道其他所有视图，由于每个视图都可能发出修改，每个视图都要知道其他所有视图，这种关联过于复杂，不但难以维护，⽽且不便于增加新的视图。

如果让模型通知所有视图更新，可能会影响模型的独⽴性。

⽤观察者(Observer)模式可以解决上述⽭盾，从⽽实现：由模型通知视图，⽽模型不依赖于具体的视图，具体视图之间相互独⽴。

视图是⽤户请求的接收者，但不宜作为请求的处理者。

因为界⾯是易变的，如果业务代码和界⾯代码放在⼀起，频繁的界⾯修改可能会破坏⽐较稳定的业务代码。

将业务逻辑分离出来，由⼀个控制器负责，就是为了避免这种⼲扰。

模型在状态变化的时候，直接通知所有视图，视图向模型查询状态数据，然后刷新⾃⾝。

当⽤户发出操作时，视图把消息发给控制器，控制器按照业务逻辑进⾏处理，需要查询或更新数据时，控制器会调⽤模型。

MVC架构把数据处理，程序输⼊输出控制及数据显⽰分离开来，并且描述了不同部件的对象间的通信⽅式。

使得软件可维护性，可扩展性，灵活性以及封装性⼤⼤提⾼；MVC(Model-View-Controller)把系统的组成分解为M（模型）、 V（视图）、C（控制器）三种部件。

视图表⽰数据在屏幕上的显⽰。

控制器提供处理过程控制，它在模型和视图之间起连接作⽤。

控制器本⾝不输出任何信息和做任何处理，它只负责把⽤户的请求转成针对Model的操作，和调⽤相应的视图来显⽰Model处理后的数据。

同样的数据，可以有不同的显⽰和进⾏各种处理。

显⽰仅仅是表现数据，⽽处理是根据⽤户请求改变数据的过程，不但包含业务逻辑，也要提供响应策略。

响应策略由控制器负责，视图可以使⽤不同的控制器提供不同的响应⽅式，这是策略(Strategy)模式的应⽤。

此外，MVC还允许视图嵌套，通过使⽤组合(Composite)模式，⼀致地处理组合视图和普通视图。

⽤多个视图表现⼀个模型，在视图不变的情况下改变响应策略，允许视图嵌套，这是MVC的三个主要特性。

在内部结构上，MVC的主要关系是由观察者模式，策略模式和组合模式给出的。

由观察者模式确定的模型视图关系是其中最为重要的。

MVC 模式有许多变体。

前述结构中，由模型通知视图刷新，称为主动MVC；如果由控制器更新模型以后通知视图，称为被动MVC结构。

在许多应⽤中，没有明显的控制器⾓⾊，也没有视图嵌套。

可见根据实际需要，构成MVC的三个模式上都可能出现变化。

Web浏览器就是被动MVC结构的⼀个实例。

" 浏览器是⼀个交互程序，从概念上讲，它是由⼀组客户、⼀组解释器与⼀个管理它们的控制器所组成。

控制器形成了浏览器的中⼼部件，它解释⿏标点击与键盘输⼊，并且调⽤其他组件来执⾏⽤户指定的操作。

例如，当⽤户键⼊⼀个URL或者点击⼀个超⽂本引⽤时，控制器调⽤⼀个客户从所需⽂档所在的远程服务器上取回该⽂档，并且调⽤解释器向⽤户显⽰该⽂档。

每个浏览器必须包含⼀个HTML解释器来显⽰⽂档，其他解释器是可选的。

HTML解释器的输⼊由符合HTML语法的⽂档所组成，输出由位于⽤户显⽰器上的格式版本⽂档所组成。

解释器通过将HTML规则转换成适合⽤户显⽰硬件的命令来处理版⾯细节。

HTML解释器⼀个最重要的功能是包含可选项。

解释器必须存储关于显⽰器上位置之间关系的信息和HTML⽂档中被瞄定的项。

当⽤户⽤⿏标选定了⼀个项，浏览器通过当前的光标位置和存储的位置信息来决定哪个项被⽤户选定。

"
2、为什么要在Web应⽤中使⽤MVC架构
⽤户界⾯逻辑的更改往往⽐业务逻辑频繁，尤其是在基于Web的应⽤程序中。

例如，可能添加新的⽤户界⾯页，或者可能完全打乱现有的页⾯布局。

对显⽰的更改，尽可能地不要影响到数据和业务逻辑。

⽬前⼤部分Web应⽤都是将数据代码和表⽰混在⼀起。

经验⽐较丰富的开发者会将数据从表⽰层分离开来，但这通常不是很容易做到的，它需要精⼼的计划和不断的尝试。

MVC从根本上强制性的将它们分开。

尽管构造MVC应⽤需要⼀些额外的⼯作，但它带来的好处是⽆庸质疑的
2.1 提⾼代码重⽤率
最重要的⼀点是多个视图能共享⼀个模型，⽆论⽤户想要Flash界⾯或是 WAP 界⾯；⽤⼀个模型就能处理它们。

由于已经将数据和业务规则从表⽰层分开，所以可以最⼤化的重⽤代码。

2.2 提⾼程序的可维护性
因为模型是⾃包含的，并且与控制器和视图相分离，所以很容易改变数据层和业务规则 [3]。

例如，把数据库从MySQL移植到Oracle，或者把基于RDBMS数据源改变到LDAP，只需改变模型即可。

⼀旦正确的实现了模型，不管数据来⾃哪⾥，视图都会正确的显⽰它们。

MVC架构的运⽤，使得程序的三个部件相互对⽴，⼤⼤提⾼了程序的可维护性。

2.3 有利于团队开发
在开发过程中，可以更好的分⼯，更好的协作。

有利于开发出⾼质量的软件。

良好的项⽬架构设计，将减少编码⼯作量：采⽤MVC结构 +代码⽣成器，是⼤多数Web应⽤的理想选择。

部分模型(Model)、和存储过程⼀般可⽤⼯具⾃动⽣成。

控制(Controller)器⽐较稳定，⼀般由于架构师（也可能是有经验的⼈）完成；那么整个项⽬需要⼿动编写代码的地⽅就只有视图(View)了。

在这种模式下，个⼈能⼒不在特别重要，只要懂点语法基础的⼈都可以编写，⽆论项⽬成员写出什么样的代码，都在项⽬管理者的可控范围内。

即使项⽬中途换⼈，也不会有太⼤问题。

在个⼈能⼒参差不齐的团队开发中，采⽤MVC开发是⾮常理想的。

3 MVC架构的优点及不⾜
3.1 MVC的优点
MVC的优点体现在以下⼏个⽅⾯：
（1）有利于团队开发分⼯协作和质量控制，降低开发成本。

（2）可以为⼀个模型在运⾏时同时建⽴和使⽤多个视图。

变化-传播机制可以确保所有相关的视图及时得到模型数据变化，从⽽使所有关联的视图和控制器做到⾏为同步。

（3）视图与控制器的可接插性，允许更换视图和控制器对象，⽽且可以根据需求动态的打开或关闭、甚⾄在运⾏期间进⾏对象替换。

（4）模型的可移植性。

因为模型是独⽴于视图的，所以可以把⼀个模型独⽴地移植到新的平台⼯作。

需要做的只是在新平台上对视图和控制器进⾏新的修改。

（5）潜在的框架结构。

可以基于此模型建⽴应⽤程序框架，不仅仅是⽤在设计界⾯的设计中。

3.2 MVC的缺点
MVC的不⾜体现在以下⼏个⽅⾯：
（1）增加了系统结构和实现的复杂性。

对于简单的界⾯，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产⽣过多的更新操作，降低运⾏效率。

（2）视图对模型数据的访问效率低。

视图可能需要多次调⽤Model才能获得⾜够的显⽰数据。

（3）完全理解MVC并不是很容易。

使⽤MVC需要精⼼的计划，由于它的内部原理⽐较复杂，所以需要花费⼀些时间去思考。

同时由于模型和视图要严格的分离，这样也给调试应⽤程序到来了⼀定的困难。

3.3 MVC 模式可以分解为以下设计模式
在GOF书的 Introduction中，有⼀⼩节是"Design Patterns in Smalltalk MVC"即介绍在MVC模式⾥⽤到的设计模式。

它⼤概向我们传达了这样的信息：合成模式+策略模式+观察者模式约等于MVC模式（当然MVC模式要多⼀些东西）。

也就是说它在⼤部分情况下是下⾯⼏个模式：
(1)、观察者模式
(2)、合成模式
(3)、策略模式
4 谈谈MVC 架构模式中的三个⾓⾊
Model （模型端）
Mod封装的是数据源和所有基于对这些数据的操作。

在⼀个组件中，Model往往表⽰组件的状态和操作这些状态的⽅法，往往是⼀系列的公开⽅法。

通过这些公开⽅法，便可以取得模型端的所有功能。

在这些公开⽅法中，有些是取值⽅法，让系统其他部分可以得到模型端的内部状态参数，其他的改值⽅法则允许外部修改模型端的内部状态。

模型端还必须有⽅法登记视图，以便在模型端的内部状态发⽣变化时，可以通知视图端。

我们可以⾃⼰定义⼀个Subject接⼝来提供登记和通知视图所需的接⼝或者继承 Java.util.Observable类，让⽗类完成这件事。

多个 View( 视图端 )
View封装的是对数据源Model的⼀种显⽰。

⼀个模型可以由多个视图，并且可以在需要的时候动态地登记上所需的视图。

⽽⼀个视图理论上也可以同不同的模型关联起来。

在前⾔⾥提到了，MVC模式⽤到了合成模式，这是因为在视图端⾥，视图可以嵌套，⽐如说在⼀个JFrame组件⾥⾯，可以有菜单组件，很多按钮组件等。

多个 Controller( 控制器端 )
封装的是外界作⽤于模型的操作。

通常，这些操作会转发到模型上，并调⽤模型中相应的⼀个或者多个⽅法（这个⽅法就是前⾯在介绍模型
的时候说的改值⽅法）。

⼀般Controller在Model和View之间起到了沟通的作⽤，处理⽤户在View上的输⼊，并转发给Model来更改其状态值。

这样 Model和View两者之间可以做到松散耦合，甚⾄可以彼此不知道对⽅，⽽由Controller连接起这两个部分。

也在前⾔⾥提到，MVC ⽤到了策略模式，这是因为View⽤⼀个特定的Controller的实例来实现⼀个特定的响应策略，更换不同的Controller，可以改变View对⽤户输⼊的响应。

MVC (Model-View-Controller) : 模型利⽤"观察者"让控制器和视图可以随最新的状态改变⽽更新。

另⼀⽅⾯，视图和控制器则实现了"策略模式"。

控制器是视图的⾏为; 视图内部使⽤"组合模"式来管理显⽰组件。

以下的MVC解释图很好的标⽰了这种模式：
模型使⽤观察者模式，以便观察者更新，同时保持两者之间的解耦。

控制器是视图的策略，视图可以使⽤不同的控制器实现，得到不同的⾏为。

视图使⽤组合模式实现⽤户界⾯，⽤户界⾯通常组合了嵌套的组件，像⾯板、框架和按钮。

这些模式携⼿合作，把MVC模式的三层解耦，这样可以保持设计⼲净⼜有弹性。