不是写在controller里面写 controller就是一个分发url的

验证一般写在model里面

大的项目 model都分层了 model获取中立的数据 如果很复杂的话 model也要分层 用户相关逻辑 可以放在 logic层

然后还可以建立一个service层 一些基本的服务是写在service层里面 service层对应的是驱动层 驱动层比如支付驱动 有支付宝 财付通 网银 等等 然后支付服务就是来链接这些支付驱动的 其实有点类似工厂+策略模式

然后 action执行动作前后 还可以Behavior行为层 定义每个执行动作前后处理的一些事情 比如说写入日志什么的

还有更多的 Widget层等等

首先，你们团队的代码是正确的，输入验证是放在model层。model是与数据交互的，按照“与谁关系最密切就与谁处理”的原则，数据验证应该由model层处理，controller只是起到一个转发的作用，与逻辑数据有关的不应该放在这里面。
关于道理和厉害关系：
说实话，这个没啥理论，就是一辈辈的开发者们经验所得。你可以将验证放在controller里面，然后开发一个大型应用试一下就知道了。
跟设计模式差不多，为什么要这样设计？完全就没有道理，完全是无数次实验之后得出的结论。然后这些不好的地方自然就成了好的道理。
以后遇到这种没有定性的问题，你自己实验一下，自然就知道哪里放哪里好了。

正所谓知道了什么不好，才真正的知道什么才是好。人生亦是如此

转一个我在别的问题(地址：http://segmentfault.com/q/1010000000633144)的回答吧。

每一层都要做，侧重点不同。

我们一般在MVC的C-M之间一定会再加一层Service层(不过也可以理解成是C或M的一部分)，这一层是设计为与View和Controller解耦，可以独立剥离出来给外部调用的(API)。

所以，
在View里面，进行比较弱的单个值的合法性校验，
在Controller里面，做外部来的请求数据包的合法性校验和部分用户接口权限校验；
在Service里面做严格的数据合法性校验、业务逻辑约束校验、用户数据权限校验；
在Model里面做数据的物理合法性校验。

另补充：
我们原则上反对在Model层做复杂的业务逻辑校验。
因为这样往往会增加Model里实体对象之间的耦合度，复用性降低。