翻译：shadowmydx 转帖请注明

最近，我计划写一个系列关于自己在过去几个月使用的Yii框架（shadowmydx：基于PHP5的一个web开发
框架，详情自行google）的文章。但在一切开始以前，我认为首先还是需要先介绍一下MVC设计模式：
模型-视图-控制器。MVC模式（30年前就有鸟）已经成为了框架以及许多各式各样的应用的首选。MVC模
式主要着眼于分离应用的显示和内在逻辑，秉承这个原则，你也许就能够在不影响应用整体运作的前提
下更加轻松的修改或者自定义应用的某个部分。

当然，基本的道理相当得容易理解，但是呢，MVC的实际实现却是比较难的。换句话说，在你真正开始
写代码以前，需要一些时间来掌握这个模式。在这篇文章里，我将从MVC模式分解的各个部分出发，讲
解这些部分之间是如何联系在一起的。在后续的文章中，我将展示这些部分是如何通信的，以及$this
（shadowmydx：php中的this写法）指针在各个部分中到底表示什么意思。

OK，让我们开始吧。MVC设计模式将应用划分为三个不同的部分：

• 模型 —— 用来表示数据
• 视图 —— 就是用户界面（用户通过这个捞批同数据交互）
• 控制器 —— 用户能够执行的动作 （shadowmydx：此处原文是which are the actions）

我认为最容易理解的部分就是模型了。这是使用和操作数据的部分。模型的一个经典表现形式就是数据
库的表，在这种情况下，每个模型的实例代表了特定表中的一行数据。注意，如果你有两个关系表，比
如说雇员和部门，这将表示成两个不同的模型，而不是一个。你会发现，把你的模型尽可能的原子化是
一个不错的选择。（shadowmydx：原文此处是keep your models as atomic as possible，原子化可以
理解为尽可能的不要组合复杂的数据为一个）其次也很重要的是，使用模型是为了操作可变的数据。举
个例子，如果你的网站有一个的“联系我们”板块，尽管用户不发邮件给你就没有数据产生，可是我们
仍然需要一个模型来管理这块数据，以防万一嘛。模型不仅仅被用于表示数据，而且也经常被用来操作
那些已经被安全输入程序处理过的用户提交数据。（shadowmydx：原文举了个例子，就是消除用户提交
的数据中的可能成为恶意代码的部分。）

视图在web开发中，也是个容易理解的部分。视图包含了HTML。很多我用过的框架，比如Yii、Zend和
Ruby On Rails，使用一个主要布局页面来安排其余的页面结构。其余的视图页面则表示了各个方面的
界面，例如表单区域啊，一个记录的列表啊，或者某个个人的记录。这些不同的小块会被放进主要布局
页面来形成一个完整的页面输出。

如果你有一个经典的雇员-部门管理应用，你也许会拥有这些视图文件：

• 一个雇员页面的主要布局页面
• 一个增加&修改雇员数据的表单
• 一个显示雇员名单的列表
• 一个显示单个雇员全部信息的区域

这些文件也可能被部门部分的视图复用，只要在部门部分的主要布局页面包含其中的某个实体进去就可
以了。

视图并不仅仅包含HTML，它们还必须有一些php语言（或者其他什么语言）的部分。这些代码只应该执
行一些非常简单的任务，例如打印某个变量的值。一个初学者经常犯的错误就是把太多的业务逻辑放到
了视图中来。视图的目标是把数据组合起来同时产生一个用户界面，视图并不应该“思考”得太多。举
个例子，视图可以使用一些条件判断来选择在什么情况下打印某个变量，或者使用循环语句来打印某个
数组，但是视图不应该做一些格式化数据或者修改数据之类的工作。假如你有一个在网站上显示用户注
册时长的功能，同时原始的数据来自数据库（换句话说，模型的一部分）并用其来计算最终显示在视图
上的结果。那么，真正的计算应该发生在模型中，而不是视图中（或者控制器中）。

控制器往往扮演一个在视图和模型之间粘合剂的角色，当然有时候并没有那么明显。（事实上，MVC设
计模式中各个部分的界限往往很容易就被模糊。）正如我之前所说，一个控制器代表了动作：一些由模
型完成的动作和一些由视图完成的动作。模型动作包括了从数据库检索单个记录或者取得全部记录，视
图动作则为对用户事件的回应：提交表单、载入页面等等。

将这些部件通过控制器组合在一起时，用户访问一个类似 www.example.com/index.php/employee/list
的页面时，将会引起一个雇员控制器中的“list”动作。这个list动作可能会调用“retrieve all”动
作来从模型中获取所有的数据。然后，这个控制器将会把数据发送给“list”视图，那个视图将会使用
一个循环打印出所有的雇员。

我将会在未来的文章中为大家展示一些真实世界的代码，请大家期待

（原文完）

【原创翻译】认识MVC设计模式：web应用开放的基础（基础篇）