【MVC】

MVC

MVC的组成

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

组件的互动

将应用程序划分为三种组件，模型 - 视图 - 控制器（MVC）设计定义它们之间的相互作用。

• 模型（Model）用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。 Model 有对数据直接访问的权力，例如对数据库的访问。Model 不依赖 View 和 Controller，也就是说，Model 不关心它会被如何显示或是如何被操作。但是 Model 中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制，那些用于监视此 Model 的 View 必须事先在此Model 上注册，从而，View 可以了解在数据 Model 上发生的改变。（比较：观察者模式(软件设计模式））
• 视图（View）能够实现数据有目的的显示（理论上，这不是必需的）。在 View 中一般没有程序上的逻辑。为了实现 View 上的刷新功能，View 需要访问它监视的数据模型（Model），因此应该事先在被它监视的数据那里注册。
• 控制器（Controller）起到不同层面间的组织作用，用于控制应用程序的流程。它处理事件并作出响应。“事件”包括用户的行为和数据Model上的改变。

聊聊视图

1. 视图不能通过下述两种方式修改模型：直接改变模型数据对象，以及调用模型的方法（会引起副作用）。也就是说，模板可以访问模型数据或调用方法，但这些访问必须是无副作用的。这条规则出现的部分原因是数据访问必须是序列无关的(order-insensitive）。
2. 视图不能对非独立数据的值（dependent data values) 进行计算。因为这样的计算将来有可能会变。任何情况下这种计算应该被封装在模型中。比如说，视图不能像这样计算图书的价格“$ price*.90”。为了独立于模型，视图不能对数据的含义做任何假设。
3. 视图不能比较非独立数据的值。但是可以检验数据的属性，如数据是否存在，多值数据的长度等。但像“$ bloodPressure < 120”这样的检验就应该放到模型中去，因为医生们总是希望能一直降低我们的最高收缩压。可以用下面这种做法代替这种表达式：“$ bloodPressureOk != null”。视图的输出可以是关于模型数据和计算的条件判断，这个条件的计算是在模型中进行的。甚至像将负数标成红色这样简单的功能都应该放到模型中去。
4. 视图不能对数据类型做任何假设。有些类型假设显而易见，比如假设一个数据值是日期。但这样一来就会存在很多狡猾的做法：比如一个模板可以假设“$ userlD”是数值型；如此程序员就不能在模型中把它修改成非数值型而不破坏这个模板。视图也不能调用有参函数了（无论静态或动态地），因为这样就会对参数类型做出假设。除非你能保证视图方法只将它们当作对象类型处理。另外，美工不是程序员，期望他们能调用函数并传递些东西进去是不现实的。
5. 模型中的数据不能包含显示信息或版面信息。模型不能将显示信息假装是数据的值进行传递。包括不能传递模板的名字到其他数据的值中。