MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

MVC框架

         MVC(model,view,controller)，一种将业务逻辑、数据、界面分离的方法组织代码的框架。在改进界面及用户交互的同时，不需要重写业务逻辑。MVC将传统的输入、处理和输出分离。

         Model：模型，逻辑部分，也是表示应用程序的核心，比如说数据库的表和记录

         View：视图，数据显示，也是表示界面，是用于显示的，比如说显示数据库的记录

         Controller：控制器，用户交互，也是表示处理的，比如说处理/增删查改数据库的记录

         MVC中，视图可以有多个，在视图中没有真正的处理，视图只作为一种数据输出的形式，一个允许用户操作的平台；模型中的代码可以被多个视图使用；控制器通过接受用户的输入、调用模型、调用视图去完成用户的请求，控制器也不做处理，只做接收请求然后通知相关的模型，再确定用哪个视图来返回数据。

         MVC将视图层和业务层分离，很容易改变应用程序的数据层和业务规则，耦合性低且可维护性高。

         MVC中的模型可以被不同的视图使用，重用性高。

Spring MVC

　　基于JAVA实现MVC设计模式的请求驱动类型的轻量型WEB框架，即使用了MVC思想，将WEB层进行解耦。

　　执行流程：浏览器发送请求给控制器，控制器接收请求将请求委托给业务对象进行处理，然后将结果使用视图渲染返回到浏览器。

简单MVC实例

图一：结构图

图二：页面介绍

以添加课程整个流程为例

1）在showCourse.jsp（View）中，有一添加课程的链接，使用action传递请求到courseServlet（Controller）

2）在courseServlet.java中，deGet方法

3）doPost方法，在其间判断action做什么

4）找到addApply，执行addApply(req,resp,out)方法

5）到上一步所说的方法，前段控制器，请求委托，到达addCourse.jsp页面

6）addCourse.jsp又再次请求，addHandin，再次到达courseServlet中

7）此时执行addHandin方法

最近负责一个项目，用了 Yii Framework 的 MVC 框架，刚开始自以为结构很稳健。

但是随着对业务逻辑理解的深入，才开始意识到问题的严重。

我错误地理解了 MVC 中的 Controller，想当然地根据以往的经验，把所有的业务逻辑都放在 Controller 的 action 中去实现。

于是，每一个 Controller 的代码都上千行，越来越臃肿。

最后，我下定决心重构代码，起源是一个对外开放 API 接口的需求。

按照现在的架构，代码基本无法复用，我需要把很多功能再重复写一遍，这实在是无法接受。

面向对象编程不仅仅是课本上的名词啊！

真正开始实践才发现，要有面向对象意识，有全局观，是多么难得的一件事情。

1 到底什么是 MVC

模型-视图-控制器（MVC）是一种设计框架（设计模式）。

MVC 的目标是将业务逻辑从用户界面的考虑中分离。

这样，开发者就可以更容易地改变每一部分而不会影响其他。

在 MVC 中，

• Model 代表数据和业务规则；

• View 包含了用户界面元素，例如文本，表单等；

• Controller 则管理模型和视图中的通信。

MVC 在各种编程语言中均有实现，例如 J2EE 应用开发中，

View 可能由 jsp 实现；Controller 是一个 servlet，现在一般用 Struts 实现；Model 则是由一个实体 Bean 来实现。

2 我遇到了什么问题

Yii Framework 是一个流行的 PHP 框架，它借鉴了 Ruby on Rails 的 ActiveRecord(AR) 概念。

数据库中的每一个 table 都可以用 AR 类来方便地进行增删改查操作。

它把 AR 当做 Model，并推荐放在一个名为 models 的目录下面。

于是，我在自动生成表对应的 AR 之后，便望文生义想当然地认为已经拥有了 Model 层。

其实，AR只不过是 DAO (数据访问层)，并不是 Model 层。

我们的业务几乎全放在了 Controller 里：对用户提交上来的表单进行各种逻辑判断，进行计算，实例化 AR 对数据进行存储……

因为一个 Controller 中会有多个 action，每个 action 都有这样的业务处理。

最后，我发现我的 Controller 代码已经超过了 1000 行。

突然有一天，leader 说，我们这个系统要开放 API 给现有的旧系统调用，要给第三方接口。

第三方只是要给定一个参数，本系统给出个结果值而已，这其中的业务处理它是不关心的。

坏就坏在这里，Controller 已经实现了那些业务，但它是接受表单提交的，怎样能够也接受 SOAP 的 xml 文档呢？

Controller 和套套一样，应该越薄越好。

它的职责应该只是接受用户的输入，然后立刻转发给别的类来处理。

这样 Controller 只负责提供不同的接口，我们才能算是将业务逻辑分离出去，而分离出去的业务也很容易进行重用。

分离出来的这部分业务由谁来处理呢？答案应该是 Model。

3 View的职责

View部分比较明确，就是负责显示。

一切与显示界面无关的东西，都不应该出现在view里面。

因此，View 中一般不应该出现复杂的判断语句，以及复杂的运算过程。

可以有简单的循环语句、格式化语句。比如，博客首页的文字列表就是一种循环。

对于PHP的Web应用而言，HTML是View中的主要内容。

View应该从不调用Model的写方法。

也就是说，View只从Model中读取数据，但不改写Model。

所以我们说，View和Model是老死不相往来的。

而且，View中不直接访问$_GET和$_POST，应该由Controller传递给View。

此外，View一般没有任何准备数据处理的内容，如查询数据库等。

这些一般是放在Controller里面，并以变量的形式传给视图。

也就是说，视图里面要用到的数据，就是一个变量。

4 Model的职责

对于Model而言，最主要就是保存和输出信息。

比如，Post类必然有一个用于保存博客文章标题的title属性，必然有一个删除的操作，这都是Model的内容。

数据、行为、方法是Model的主要内容。

实际工作中，Model是MVC中代码量最大。

Model是逻辑最复杂的地方，因为应用的业务逻辑也要在这里表示。

注意将Model与Controller区分开。

Model是处理业务方面的逻辑，Controller只是简单的协调Model和View之间的关系。

只要是与业务有关的，就该放在Model里面。

数据校验、public常量和变量，都应该放在model层，

也就是说，有可能被重复使用的属性或方法，都应该放在model层，一次定义，到处使用。

Model不应该访问request、session以及其他环境数据，这些应该由Controller注入。

好的设计，应该是胖Model，瘦Controller。

5 Controller的职责

对于Controller，主要是响应用户请求，决定使用什么视图，需要准备什么数据用来显示。

因此，对于request的访问代码，应该放在Controller里面，比如$_GET、$_POST等。

Controller应该仅限于获取用户请求数据，不应该对数据有任何操作或预处理，这应该放在 Model 里面。

对于数据的写操作，要调用Model类的方法完成。

对于用户请求的响应，要调用视图渲染。

此外，一般不要有HTML代码等其他表现层的东西，这应该是属于View的内容。

6 启示

Yii Framework 的官方文档中有这么一段：

In a well-designed MVC application, controllers are often very thin, containing probably only a few dozen lines of code; while models are very fat, containing most of the code responsible for representing and manipulating the data.

简言之，Rich Model is Better。

• 框架
• MVC