目前大家使用mvc开发框架的时候，对于用户前端的用户录入性文字合法性检测的时候，在用户提交的时候，这个应该由c层来处理还是m层来处理？
其实合法性检查也分本地和服务器端。
例如输入为空，是放在 V 层来检查；输入的格式不对事放在 M 层来检查。
如果要进一步检查是否合格更是放在 M 层通过访问服务器来检查。
这个问题需要结合具体应用、具体语言、具体框架分析，甚至和团队成员的风格、构成有关。
我个人倾向于M做校验逻辑，抛异常，然后C捕捉并转换为前端需要的格式输出。这样初期代码可能啰嗦一点，但对逻辑完整性和后期扩展比较有利。
还有一种做法是在M和C中间建立一层所谓逻辑层，来处理校验逻辑和部分业务逻辑
鹅厂编码有个原则：接口间互不信任。
每一层都要做，侧重点不同。
我们一般在MVC的C-M之间一定会再加一层Service层(不过也可以理解成是C或M的一部分)，这一层是设计为与View和Controller解耦，可以独立剥离出来给外部调用的(API)。
所以，
在View里面，进行比较弱的单个值的合法性校验，
在Controller里面，做外部来的请求数据包的合法性校验和部分用户接口权限校验；
在Service里面做严格的数据合法性校验、业务逻辑约束校验、用户数据权限校验；
在Model里面做数据的物理合法性校验。
简单的MVC一般会把FORM验证做在model层上，而比较成熟的方案一般会把FORM分出来，以joomla为例，它有FORM层并整合到model层上，结构上是属于model层，但功能的实现又似乎跟model层没什么关系。
如果题主使用过Python的Django或者Flask这样的框架的话，会发现还有一个Form类。用户内容验证的逻辑，一般来说会放在Form类里面来做。因为有时候，我们可能需要根据不同的情况，针对同一个Data model做不同的验证规则。当然Django也支持Model层的验证。相对而言。Form层来做这个，耦合度更低一点。
M层，C层不验证。一般M层上面都会有Service，一般都是在Service里做处理。
为啥不在Controller里做验证，因为要兼顾webservice，同样的业务对于页面和webservice是俩Controller，所以写在Controller里无法代码重用了
不得不顶一下易伟的说法 ，我补充下我的理解，V为保证用户体验而做校验，不至于让用户提交之后发现出错了在回去改，C为保证数据本身的合法性而校验（数据是否属于该用户，数据状态改变是否符合逻辑要求），M为保证数据存在性而交易，数据都不存在，下面的都不用走了，肯定是异常了。
这绝对要分情况看的：
- 文本格式的合法性：在前端用js验证或正则表达式处理掉就好。
- 数据的有效性问题：
- 简单情况：比如验证年月日的合法性，同样可以放在前端来做。
- 更广泛的情况：包含以上两种情况，也包含用户名验证、重复性验证等，牵扯具体业务逻辑的情况，以Rails框架为代表，是放在Model中完成验证的。
Fat model, skinny controller.
Model层。首先Controller不做任何验证，View层也可以做验证，但一般放在model层
不用任何框架自己写的话应该属于c层。但是更多的框架倾向于放在m层里面。
另外不要只在v层做输入校验，前端的东西很容易被绕过，有安全隐患。
一般MVC框架中会根据业务处理增加一层service层，model做ORM映射或者直接抛弃，写个DAO，好了，现在来说下校验到底在哪层里面做，最正确的方法是控制器层C和服务层S都要做，因为随着网站发展，肯定是需要将service单独拎出来，做为公共的服务组件，进行远程调用，所以如果你不在控制器层做校验的话，今后有数据请求，你直接丢给公共的服务，如果数据有问题，然后再返回错误，这很明显就浪费了一次网络IO,所以如果你已经在控制器层面做好数据校验了，当数据有误，直接抛出异常，不需要再通过RPC取进行一次远程调用了
M层
你要记住：MVC
M层处理一切和数据有关的内容。
V层处理一切和数据展示有关的内容。
C层就想一个数据的管道，来链接这些内容。