为什么要提倡thin controller & fat model的架构? [ 求助交流 ]

我是感觉model厚重些好，controller就可以精悍些。这样controller里的各个action方法就可以减少重复代码。这是我用过的。

你说的两个不同controller之间的代码复用我没有遇到。

不知道是不是这个意思。

按照正统思想, 你这会背扣上不和章法的帽子

其实也无所谓了 看你心情咯

controller 势力范围内体现的是业务逻辑,

因此 要尽量精简, 最好懒一点, 指哪儿打哪儿, 只会吆喝是最棒的了... 丫就是个颐指气使的指挥官

任务的具体实现, 是不糅杂业务逻辑在内的. 这些最好在model领域完成

合理的分割 设计尤为重要.. 各种大多设计模式恐怕是在这个战场上被探索总结出来的...

目的也很明确, 无外乎最大化复用, 今后维护轻松一点 读起来赏心悦目一些..... and so on...

请注意 我说的都是 controller势力范围 model领域 ....

说到底, 是一个概念吧, 代表一种思想吧, 亦或是几个高逼格词而已 但绝逼不是一个类似文件什么的玩意儿

router 路由：是交通体系里的道标、路牌，用于指引方向。

model 模型：是某一种交通规则，涵盖了这个情景下的各种约束与方案，不可被具体触摸的规则。

views 视图：是道路、桥、高架、隧道、高速公路，是一切和你息息相关，可以被你感知和触摸到的很具体的物体。

controller 控制器：是驱动力，驾驶员做出抉择，交通工具负责执行，交警负责裁决。他是链接有形与无形之间的纽带。

以上是我举的一个例子，这套体系的目的是为了达成快速、高效、安全的交通体系，在程序中亦然。我们不可能为每条道路制定各种规则，因为绝大部分道路的交通规则都是重复的，那样造路的人要累死。所以需要model来进行统一控制，当有规则改变时只需要在model里与view里调整即可，其他地方几乎不需要改变（类似与交通部发个文件说长假高速免费，然后高速公路上竖个牌子告知一样。）

那么想想，如果你把过多的事情放在了controller里处理，产生最大的问题就是效率，因为驾驶员、交通工具、交警之间的关系变复杂了，必然导致效率变低了，而且可能出现每个交警执法过程中标准不统一的问题。

所以在控制器里做大量的工作可能本末倒置了。