MVC模型的简单总结

[size=small]一、 MVC模型的简单介绍[/size]

　　MVC模型源自于传统的面向对象语言Smalltalk,首先被应用在Smalltalk-80环境中，是许多交互和界面系统的构成基础。MVC结构是为那些需要为同样的数据提供多个视图的应用程序设计的，它很好的实现了数据层和表示层的分离。MVC作为一种开发模型，通常用于分布式系统的设计和分析中，以及用于确定系统各部分之间的组织关系。

　　根据模块的用途和界面设计可变性的需求，MVC把交互系统的组成分解成模型、视图、控制器三层。这三层的分离使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据，所有依赖于这些数据的视图都应反映到这些变化。因此，无论何时发生了何种数据的变化，控制器都将变化通知所有的视图，导致显示的更新。

　　模型层（Model） : 业务逻辑模块，表示应用领域有关的类别、物体、数据结构以及企业业务逻辑等。通常，Model是企业业务流程的软件近似模型，所以，在定义Model时只需对企业业务流程中的对象进行合理抽象、封装对象的属性和对象隐含的业务逻辑即可。

　　视图层（View）: 用户视图模块，一方面，它为用户提供了输入手段，并触发Controller运行；另一方面，它通过Model访问企业数据，并用某方式显示这些数据。同时，当Model 变化时，它做出相应变化。用两种方法之一：Push(推)模式，让View在Model处注册，以便在Model变化时获得提醒；Pull(拉)模式，View在需要获得最新数据时调用Model。

　　 控制层（Controller:） 流程控制模块，将用户与View的交互转换为基于应用程序行为的标准业务事件，再将标准业务事件解析为Model应执行的动作。Model执行的动作包括激活业务逻辑和改变Model的状态。根据用户交互信息和Model执行动作的结果，Controller选择一个合适的View.展现给客户。

　　传统的MVC模型只是从概念上将视图从流程控制、业务逻辑独立出来，并定义了相互间作用的机制，使各个模块的开发相对独立，但是它没有针对不同视图类型，解决流程控制等对象的统一问题。


[size=small]二、 MVC模型的优点[/size]

1. 低耦合性，视图层和业务层的分离，可以使得更改视图层的代码而不用重新编译模型和 控制器代码。三层分离，又增加了程序设计的灵活性，当一个应用的业务流程或者业务规则需要改变时只需改动MVC的模型层，而界面表现的改变只需改动MVC的视图层。

2. MVC的三层分离可以让不同的开发者负责不同的模块，就可以分工，分工就可以快速部署，就可以提高效率，相当大的缩短开发时间，按照传统的责任划分来处理软件开发过程，使开发者专心于一个领域，从而极大地提高了软件的开发效率，也因此，MVC模型适合于团队开发。

3. 高重用性和可试性，MVC模式允许使用各种不同样式的视图来访问同一个服务器的代码，包括任何WEB（HTTP）浏览器或者无线浏览器（WAP）。

4. 可维护性，三层的分离使得WEB应用更易于维护和修改。

5. 较低的生命周期成本。

6. 有利于软件工程化管理，不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于工程化、工具化管理程序代码。

7. 模型的部分，因为足够抽象，可以方便地重复利用，另一方面利用单元测试工具对模型进行单元测试，保证工程质量。


[size=small]三、 MVC模型的缺点[/size]

1. 增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图和控制器分离，会增加结构的复杂性，并肯能产生过多的更新操作，降低运行效率。

2. 视图与控制器过于紧密的连接。视图与控制器是相互分离的，但却又是联系紧密的部件，视图没有控制器的存在，其应用是有限的，反之亦然，这就妨碍了他们的独立重用。

3. 视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对为变化数据的不必要的频繁访问，也将损害操作。

4. MVC模式应用于J2ME上增大了代码体积。据不完全统计，使用了MVC模式后，代码体积约是不是用的1.5倍，这对于存储容量十分有限的移动设备是致命的。

5. MVC的3个定义不是很具体，对于3个部件的具体功能还存在着一些争议，给初学者留下不少陷阱，加大了使用MVC模式的难度。

6. 目前，一般高级的界面工具或构造器不支持MVC模式，改造这些工具一适应MVC需要和建立分离的部件的代价很高，从而也造成了使用MVC的困难。