不得不顶一下易伟的说法 ，我补充下我的理解，V为保证用户体验而做校验，不至于让用户提交之后发现出错了在回去改，C为保证数据本身的合法性而校验（数据是否属于该用户，数据状态改变是否符合逻辑要求），M为保证数据存在性而交易，数据都不存在，下面的都不用走了，肯定是异常了。

这个问题需要结合具体应用、具体语言、具体框架分析，甚至和团队成员的风格、构成有关。

我个人倾向于M做校验逻辑，抛异常，然后C捕捉并转换为前端需要的格式输出。这样初期代码可能啰嗦一点，但对逻辑完整性和后期扩展比较有利。

还有一种做法是在M和C中间建立一层所谓逻辑层，来处理校验逻辑和部分业务逻辑

一般MVC框架中会根据业务处理增加一层service层，model做ORM映射或者直接抛弃，写个DAO，好了，现在来说下校验到底在哪层里面做，最正确的方法是控制器层C和服务层S都要做，因为随着网站发展，肯定是需要将service单独拎出来，做为公共的服务组件，进行远程调用，所以如果你不在控制器层做校验的话，今后有数据请求，你直接丢给公共的服务，如果数据有问题，然后再返回错误，这很明显就浪费了一次网络IO,所以如果你已经在控制器层面做好数据校验了，当数据有误，直接抛出异常，不需要再通过RPC取进行一次远程调用了

这绝对要分情况看的：

• 文本格式的合法性：在前端用js验证或正则表达式处理掉就好。
• 数据的有效性问题：
  
  
  • 简单情况：比如验证年月日的合法性，同样可以放在前端来做。
  • 更广泛的情况：包含以上两种情况，也包含用户名验证、重复性验证等，牵扯具体业务逻辑的情况，以Rails框架为代表，是放在Model中完成验证的。

Fat model, skinny controller.

鹅厂编码有个原则：接口间互不信任。

不用任何框架自己写的话应该属于c层。但是更多的框架倾向于放在m层里面。

另外不要只在v层做输入校验，前端的东西很容易被绕过，有安全隐患。

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

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

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

如果题主使用过Python的Django或者Flask这样的框架的话，会发现还有一个Form类。用户内容验证的逻辑，一般来说会放在Form类里面来做。因为有时候，我们可能需要根据不同的情况，针对同一个Data model做不同的验证规则。当然Django也支持Model层的验证。相对而言。Form层来做这个，耦合度更低一点。

简单的MVC一般会把FORM验证做在model层上，而比较成熟的方案一般会把FORM分出来，以joomla为例，它有FORM层并整合到model层上，结构上是属于model层，但功能的实现又似乎跟model层没什么关系。

其实合法性检查也分本地和服务器端。
例如输入为空，是放在 V 层来检查；输入的格式不对事放在 M 层来检查。
如果要进一步检查是否合格更是放在 M 层通过访问服务器来检查。