MVC架构的职责划分原则
最近负责一个项目，用了 YiiFramework的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我遇到了什么问题
YiiFramework是一个流行的PHP框架，它借鉴了RubyonRails的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。
3View的职责
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。
5Controller的职责
对于Controller，主要是响应用户请求，决定使用什么视图，需要准备什么数据用来显示。
因此，对于request的访问代码，应该放在Controller里面，比如$_GET、$_POST等。
Controller应该仅限于获取用户请求数据，不应该对数据有任何操作或预处理，这应该放在Model里面。
对于数据的写操作，要调用Model类的方法完成。
对于用户请求的响应，要调用视图渲染。
此外，一般不要有HTML代码等其他表现层的东西，这应该是属于View的内容。
6启示
YiiFramework的官方文档中有这么一段：
Inawell-designedMVCapplication,controllersareoftenverythin,containingprobablyonlyafewdozenlinesofcode;whilemodelsareveryfat,containingmostofthecoderesponsibleforrepresentingandmanipulatingthedata.
简言之，RichModelisBetter。
参考资料：
- MVC之患上肥胖症的Controller
- MVC的划分原则
- 我们丢失了Model层
- MVC演化史