MVC框架

MVC的定义

MVC模式（Model–view–controller）是软件工程中的一种软件架构模式，把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。

MVC模式的目的是实现一种动态的程序设计，使后续对程序的修改和扩展简化，并且使程序某一部分的重复利用成为可能。除此之外，此模式透过对复杂度的简化，使程序结构更加直观。软件系统透过对自身基本部分分离的同时也赋予了各个基本部分应有的功能。专业人员可以依据自身的专长分组。

模型（Model） - 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。
视图（View） - 界面设计人员进行图形界面设计。
控制器（Controller）- 负责转发请求，对请求进行处理。

MVC三者之间详细说明与联系

###详细说明

MVC模式在概念上强调 Model, View, Controller 的分离，各个模块也遵循着由 Controller 来处理消息，Model 掌管数据源，View 负责资料显示的职责分离原则，因此在实现上，MVC 模式的 Framework 通常会将 MVC 三个部分分离实现：

Model 负责资料访问，较现代的 Framework 都会建议使用独立的资料对象 (DTO, POCO, POJO 等) 来替代弱类型的集合对象。资料访问的代码会使用 Data Access 的代码或是 ORM-based Framework，也可以进一步使用 Repository Pattern 与 Unit of Works Pattern 来切割数据源的相依性。

Controller 负责处理消息，较高端的 Framework 会有一个默认的实现来作为 Controller 的基础，例如 Spring 的 DispatcherServlet 或是 ASP.NET MVC 的 Controller 等，在职责分离原则的基础上，每个 Controller 负责的部分不同，因此会将各个 Controller 切割成不同的文件以利维护

View 负责显示资料，这个部分多为前端应用，而 Controller 会有一个机制将处理的结果 (可能是 Model, 集合或是状态等) 交给 View，然后由 View 来决定怎么显示。例如 Spring Framework 使用 JSP 或相应技术，ASP.NET MVC 则使用 Razor 处理资料的显示。

联系

View 传送指令到 Controller
Controller 完成业务逻辑后，要求 Model 改变状态
Model 将新的数据发送到 View，用户得到反馈
所有通信都是单向的。View和Model之间的通信是通过Controller来作为桥梁的，也就是说View和Model并不是直接通信；
需要服务器端配合，JavaScript可以在前端修改服务器渲染后的数据，所有通信都是单向的，提交一次反馈一次，通信一次相互制约。

MVC的优点与缺点

优点

多个 View 能共享一个 Model
- 同一个Web应用程序会提供多种用户界面，例如用户希望既能够通过浏览器来收发电子邮件，还希望通过手机来访问电子邮箱，这就要求Web网站同时能提供Internet界面和WAP界面。在MVC设计模式中， Model 响应用户请求并返回响应数据，View 负责格式化数据并把它们呈现给用户，业务逻辑和表示层分离，同一个 Model 可以被不同的 View 重用，所以大大提高了代码的可重用性。
Controller 是自包含（self-contained,指高独立内聚）的对象，与 Model 和 View 保持相对独立，所以可以方便的改变应用程序的数据层和业务规则。
- 把数据库从MySQL移植到Oracle，或者把RDBMS数据源改变成LDAP数据源，只需改变 Model 即可。一旦正确地实现了控制器，不管数据来自数据库还是LDAP服务器，View 都会正确地显示它们。由于MVC模式的三个模块相互独立，改变其中一个不会影响其他两个，所以依据这种设计思想能构造良好的少互扰性的构件，降低了耦合度
Controller 提高了应用程序的灵活性和可配置性
- Controller 可以用来连接不同的 Model 和 View 去完成用户的需求，也可以构造应用程序提供强有力的手段。给定一些可重用的 Model 、 View 和Controller 可以根据用户的需求选择适当的 Model 进行处理，然后选择适当的的 View 将处理结果显示给用户。
增强了软件工程所要求的可测试性(Testablity)
- MVC-based 的应用程序在良好的职责分离的设计下，各个部分可独立行使单元测试，有利于与企业内的自动化测试、持续集成 (Continuous Integration) 与持续发行 (Continuous Delivery) 流程集成，减少应用程序改版部署所需的时间。

缺点

不适合小型中等规模的应用程序；
增加了系统结果和实现的复杂性；
View和Model之间不匹配，用户界面和流程要考虑易用性，用户体验优化同时考虑业务流程的精确和无错。
Controler和Model之间界线不清，什么样的逻辑是界面逻辑，什么样的逻辑是业务逻辑，很难定义清楚。没有明确的定义；
View的变化不能完全由Model控制，即Observer模式不足以支持复杂的用户交互。这其实要求VC之间要有依赖。牵一发而动全身，数据，显示不分离，Controller，Model联系过于紧密。

扩展：MVP

定义：

MVP（Model-View-Presenter）是MVC的改良模式，由IBM的子公司Taligent提出。和MVC的相同之处在于：Controller/Presenter负责业务逻辑，Model管理数据，View负责显示。只不过是将 Controller 改名为 Presenter，同时改变了通信方向。

MVP的特点

M、V、P之间双向通信。
View 与 Model 不通信，都通过 Presenter 传递。Presenter完全把Model和View进行了分离，主要的程序逻辑在Presenter里实现。
View 非常薄，不部署任何业务逻辑，称为”被动视图”（Passive View），即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。
Presenter与具体的View是没有直接关联的，而是通过定义好的接口进行交互，从而使得在变更View时候可以保持Presenter的不变，这样就可以重用。不仅如此，还可以编写测试用的View，模拟用户的各种操作，从而实现对Presenter的测试–从而不需要使用自动化的测试工具。

MVP的优缺点

MVP的优点

模型与视图完全分离，我们可以修改视图而不影响模型；
可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部；
我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁；
如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）。

MVP的缺点

视图和Presenter的交互会过于频繁，使得他们的联系过于紧密。也就是说，一旦视图变更了，presenter也要变更。