深刻浅出MVC框架模式

深刻浅出MVC模式

 

1、MVC模式概述

模型-视图-控制器（MVC模式）是一种很是经典的软件架构模式，在UI框架和UI设计思路中扮演着很是重要的角色。从设计模式的角度来看，MVC模式是一种复合模式，它将多个设计模式在一种解决方案中结合起来，用来解决许多设计问题。MVC模式把用户界面交互分拆到不一样的三种角色中，使应用程序被分红三个核心部件：Model（模型）、View（视图）、Control（控制器）。它们各自处理本身的任务：

（1）模型：模型持有全部的数据、状态和程序逻辑。模型独立于视图和控制器。

（2）视图：用来呈现模型。视图一般直接从模型中取得它须要显示的状态与数据。对于相同的信息能够有多个不一样的显示形式或视图。

（3）控制器：位于视图和模型中间，负责接受用户的输入，将输入进行解析并反馈给模型，一般一个视图具备一个控制器。

MVC模式将它们分离以提升系统的灵活性和复用性，不使用MVC模式，用户界面设计每每将这些对象混在一块儿。MVC模式实现了模型和视图的分离，这带来了几个好处。

（1）一个模型提供不一样的多个视图表现形式，也可以为一个模型建立新的视图而无须重写模型。一旦模型的数据发生变化，模型将通知有关的视图，每一个视图相应地刷新本身。

（2）模型可复用。由于模型是独立于视图的，因此能够把一个模型独立地移植到新的平台工做。

（3）提升开发效率。在开发界面显示部分时，你仅仅须要考虑的是如何布局一个好的用户界面；开发模型时，你仅仅要考虑的是业务逻辑和数据维护，这样能使开发者专一于某一方面的开发，提升开发效率。

图1.1MVC模式结构图

如图1.1所示，视图中用户的输入被控制器解析后，控制器改变状态激活模型，模型根据业务逻辑维护数据，并通知视图数据发生变化，视图获得通知后从模型中获取数据刷新本身。

 

2、深刻解析MVC模式

对MVC模式有了一个初步的认识以后，咱们能够继续深刻地了解它。MVC模式的关键是实现了视图和模型的分离。这是如何实现的呢？MVC模式经过创建一个“发布/订阅”（publish-subscribe）的机制来分离视图和模型。发布－订阅（publish-subscribe）机制的目标是发布者，它发出通知时并不需知道谁是它的观察者。能够有任意数目的观察者订阅并接收通知。MVC模式最重要的是用到了Observer（观察者模式），正是观察者模式实现了发布－订阅（publish-subscribe）机制，实现了视图和模型的分离。所以谈到MVC模式就必须谈到观察者模式。如图2.1所示。

图2.1 观察者模式

观察者模式：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，全部依赖于它的对象都获得通知并被自动更新。

图2.1中Subject咱们称为主题，Observer称为观察者。主题提供注册观察者、移除观察者和通知观察者的接口，这样只要观察者注册成为主题的一个观察者的话，主题在状态发生变化时会通知观察者。观察者有一个更新本身的接口，当收到主题的通知以后观察者就会调用该接口更新本身。如何实现注册和通知的呢？若是是用C++或java的话，主题就须要有一个观察者链表，注册就是将观察者加入到该链表中，移除则是从该链表中删除，当主题状态变化时就遍历该链表全部的观察者通知它们更新本身。在c#中能够经过委托实现注册。

       观察者模式中的主题就对应于MVC模式中Model（模型），观察者就对应于MVC模式中的View（视图）。视图向模型注册成为观察者，模型（主题）变化时就通知视图（观察者）更新本身，可是还有一个问题，咱们若是不引入控制器的话，直接将接受用户输入并解析输入操纵模型的功能放到视图中的话会产生两个问题：第1、会形成视图代码变得复杂，使得视图就有了两个责任，不但要管理用户界面，还要处理如何控制模型的逻辑，有违单一责任的设计原则，一个类应该仅有一个引发它变化的缘由，若是一个类承担的责任过多，就等于把这些责任耦合在一块儿，一个责任的变化可能会削弱或抑制这个类完成其余责任的能力，这种耦合会致使脆弱的设计，当变化同时面临两个或多个方向变化时设计会遭到意想不到的破坏甚至根本没办法处理。第2、会形成模型和视图的紧耦合，若是你想复用此视图来处理其余模型，根本不可能。因而把控制器从视图中分离出来，将视图和模型解耦，经过控制器来保持控制器和视图之间的松耦合，使设计更有弹性和容易扩展，足以容纳之后的改变。

控制器至关因而视图的行为，咱们还要考虑到从此可能面临的变化，例如视图想换一种行为，咱们是否作好了应付这种变化的准备呢？咱们不该该将视图和控制器紧耦合，例如不要一开始就将视图和某一个具体行为绑定起来，这样会使视图更换行为的时候变得很困难，咱们应该能动态的给视图指定一个行为，用多态使视图和控制器之间松耦合，可使视图轻松地更换行为，因而策略模式登场了，策略模式正是用来解决这个问题的。如图2.2所示。   

       策略模式：定义了算法族，分别封装起来，让他们之间能够相互替换，此模式让算法的变化独立于使用算法的客户。

       MVC模式视图和控制器实现了经典的策略模式：视图是一个对象，能够被调整使用不一样的策略（行为），而控制器提供了策略（行为）。视图想换另外一种行为，换控制器就能够了。视图只关心系统中可视的部分，对于任何界面行为，都委托给控制器处理。使用策略模式也可让视图和模型之间的关系解耦，由于控制器负责和模型交互来传递用户的请求。对于工做是怎么完成的，视图绝不知情。

 

图2.2策略模式

3、MVC模式的应用

       GOF四人组提出MVC模式的主要关系是由Observer（观察者模式）、Composite（组合模式）和Strategy（策略模式）三个设计模式给出的。固然其中还可能使用了其余的设计模式，这要根据具体场景的须要来决定。GOF四人组提出复杂的视图能够根据实际须要用组合模式来实现，固然，也要注意避免过分设计，若是视图的结构不复杂就不必采用组合模式了。咱们和一个同事一块儿开发的项目中，UI框架的设计我采用了MVC模式，主要结合了Observer（观察者模式）、Strategy（策略模式）、Command（命令模式）和Singleton（单件模式）。用户界面不太复杂，所以视图不须要应用组合模式，在界面的框架设计中，界面菜单、对话框、树形控件和表格控件对应于MVC模式中的View（视图），其中对话框采用了单件模式，保证一个类仅有一个对话框实例，并提供一个访问它的全局访问点。控制器位于视图和命令对象或模型中间，将界面请求封装成一个命令对象，命令对象执行控制器发送过来的命令，根据命令对象模型负责处理逻辑和数据。项目UI框架中采用Observer（观察者模式）和Strategy（策略模式）使视图和模型分离，并让视图能灵活地更换行为，在前面已有详述，再也不赘述，我要重点提的是我为何要采用Command（命令模式）以及如何将命令模式嵌入到MVC模式当中。如图3.1所示。

图3.1 命令模式

命令模式：将一个请求封装为一个对象，从而使你可用不一样的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操做。

根据项目的需求：用户能够经过工具条按钮、菜单按钮、对话框按钮或鼠标右键等操做来执行同一项请求；支持取消和重作操做；很容易增长或更换新的命令请求。这些问题均可以经过命令模式来解决。命令模式可使不一样地方的按钮或操做表明同一项功能，只须要让它们共享响应具体Command子类的同一实例便可。还能够经过多态动态替换Command对象从而轻松地更换请求命令。Command的Execute操做可在实施操做前将状态存储起来，在取消操做时这个状态用来消除该操做的影响。Command具体对象调用一个Unexecute操做，该操做取消上一次Execute调用的效果。执行的命令被存储在一个历史列表中。可经过向后和向前遍历这一列表并分别调用Unexecute和Execute来实现次数不限的“取消”和“重作”。Command模式将调用操做的对象与知道如何实现该操做的对象解耦。Command可像其余的对象同样被方便的替换和扩展。在菜单中增长新的调用命令时只要增长新的Command，而无需改变已有的类。咱们将Command对象放到控制器中，控制器接收视图的输入并解析，将用户输入发送给Command对象，Command对象调用执行接口，而后在Command子类中将用户输入发给模型，模型执行逻辑维护数据，并通知视图。视图获得通知后获取模型的新数据并更新本身。项目的界面框架采用这种MVC模式使得软件变得灵活、易于扩展和维护。

 

4、结论

在软件开发的过程当中，开发人员最为担忧的是需求的不断变化，而这些变化又不是开发人员所能控制的，所以，为了适应这些变化，就要使用设计模式。MVC模式在一个解决方案中综合运用多种设计模式，是模式中的模式，按MVC模式的设计，一个模型能够表现为多个视图，这样能够减小代码的冗余。模型返回的数据不带任何显示格式，所以这些模型也可直接应用于接口的使用。因为一个应用程序被分离为三层，所以有时改变其中的一层就能知足应用的改变。一个应用的业务流程或者业务规则的改变只需改动MVC的模型层，而不会影响到视图和控制器。不过，使用设计模式并非必定就能获得一个好的设计，过度地使用设计模式会增长程序的复杂性和晦涩性，让程序不易理解，从而下降了程序的易维护性。所以要避免过分使用设计模式，咱们应根据面向对象的设计原则和实际状况综合考虑咱们的设计，从而设计出具备良好扩展性和易维护性的软件。