（转自：http://www.cnbeta.com/articles/107924.htm）
MVC不是一种设计模式（design pattern），它是一种架构模式（Architectural pattern），用以描述应用程序的结构以及结构中各部分的职责和交互方式。
它最先是在1979年的时候第一次被人提出，不过，当时环境有些不同，网络应用的概念在当时还不存在。提姆·伯纳斯李在上世纪九十年代初期的时候播种下了万维网（WWW）的种子，并永远的改变了世界。目前我们在网络开发中所采用的这种模式实际上是原版模式的一个改编版。
这种架构模式的疯狂流行是由于两个极其流行的开发框架将这种模式包含了进来，它们是：Struts 和 Ruby on Rails。这两个开发框架给稍后诞生的数百框架打上了深深的烙印。
网络应用中的MVC模式
模型-视图-控制器架构模式背后的思想非常简单：我们的应用程序中必须区分下面这些职责：
应用程序被分成了三个主要的部分，每个部分负责掌管不同的任务。下面让我们看看详细的解释以及一个例子。
控制器
控制器掌管着用户的请求（当用户点击图形用户界面（GUI）上的元素执行操作时，控制器会收到HTTP GET或者POST请求）。它的主要功能就是调用并协调需要的资源/对象来执行用户请求。通常控制器会为任务调用合适的模型，以及选择合适的视图。
模型
模型是指运用于数据之上的数据规则和数据内容，它一般对应于应用程序所要管理的对象。在软件系统中，任何事物都可以被抽象成可以对其以某种方式进行处理的数据模型。应用程序中的用户，信息以及图书是什么？它们只是一堆必须按照对应规则处理的数据（日期不能是未来的日期，电子邮件有特定的格式，名字的长度不能超过多少字符等等）
模型给控制器提供了一个用户请求内容对应的数据表达（比如信息，书，相册）。不管我们如何向用户展示，这个数据模型都不会变。这也是我们为什么可以随意选择使用哪个视图来展示数据的原因。
模型包含我们应用程序逻辑中最重要的组成部分，这些逻辑运用于我们要处理的问题过程中。控制器更多的是包含应用程序自身的内部组织逻辑（更像管家）。
视图
视图提供了展示模型数据的不同方式。它可能是数据填充的模板。视图可以有多个，而控制器则决定使用哪个视图。一个网络应用通常由许多控制器，模型和视图组成。控制器可以被看成是一个主控制器，用于接收用户的所有请求，然后在调用特定的控制器来处理不同的情况。
让我们看一个例子
现在，假设，我们正在开发一个在线书店。用户可以进行如下操作：查看图书。注册，购买，往当前订单添加物品，创建和删除图书（如果他有管理员权限的话）。现在让我们看看当用户单击“幻想”门类来查看该门类下有哪些书时会发生什么情况。
我们会有一个特定的控制器来处理所有与图书相关的操作（查看，编辑，创建等操作）。这个例子中，我把该控制器命名为 books_controller.php。我们也会有一个模型（比如 book_model.php）来处理数据和与商店中图书物品相关的逻辑。最后我们还有一些视图来展示数据，比如图书清单，一个编辑图书的页面等等。
下面这幅图展示的是用户发出的查看请求是如何处理的：
控制器（books_controller.php）以HTTP GET或者POST的方式接收到用户的请求[1]（我们也可以有一个主控制器，比如index.php 来接收请求，然后它再调用ooks_controller.php）
控制器检查请求以及对应的参数，然后调用模型（book_model.php），请求模型返回幻想类的图书[2]。模型负责从数据库中调取信息 [3]，如有需要它可以加入过滤和逻辑，然后返回图书列表。
控制器使用恰当的视图来将这些数据展示给用户[6-7]，如果用户还选择了特定皮肤，对应的视图文件也会被选上等等。
MVC的好处是什么
我们使用MVC的一个最明显好处就是它将视图展示和应用逻辑清晰的分离开来。
对不同用户以及不同设备类型的支持一直是当下的一个常见问题。来自台式电脑和手机的请求所得到的视图应该是不相同的。模型会返回完全相同的数据，但是不同的地方是控制器会选择使用的视图文件来展示数据（我们可以把它看作是不同的模板）。
除了将视图从业务逻辑中分离开外，MVC的分离也降低了大型应用设计的难度。代码也更具结构性，因此也更容易维护，测试和重用。
但是为什么要框架呢？
当你使用一个框架时，MVC的基本结构已经包含在其中，你只需对这些结构进行扩充，将你的文件遵照MVC的模式放置到合适的目录中去。而且它也提供许多现成并且经过完全测试的功能。