验证写在controller还是model里？
之前团队留下的模型代码都是这样的：
public function getcount($where){
if(!empty($where)){
$db->where($where);
}
$db->from($tablename);
return $db->count_all_results();
}
————————
function edit($tid,$data){
$db->where('tid', $tid);
return $db->update($tablename, $data);
}
MODEL里这样写这样的纯粹的增删改查有什么优点？
验证部分究竟应该放在哪里比较好
？
请阐明其中的道理和厉害关系。
之前可能有人看的太快导致的误解，上述代码的model里面那个empty并不算真的判断，关于$where参数，是需要严格按照数据库对应的字段拼装，而model里并没有任何判断，严重依赖控制器喂给它正确的参数。
项目经理铁定要求在控制器处理验证，所以现在的控制器里有数量可观的巨型函数（需要调用model的地方都超过150行了），而且格式基本近似。
举个例子，现在的情况是：
view提交表单到controller，在那里验证表单，呼叫model，并为model拼装数组参数（如同上面代码里那样）。
看到后来新的答案里有些说的情况比较模糊，比如“复杂逻辑”这样还是没法明确。所以，我再细化一下问题：
现在的model里仅仅是转发了一下sql的增删改查的基本操作，在控制器里调用这些model的时候，我必须严格根据数据库里的字段名来拼装$data数组，这就基本等同于没有model，还不如控制器里直接拼sql算了。
laravel codeigniter php thinkphp mvc
我不是小哲
10 years, 10 months ago
Answers
验证代码应该写在服务层
那么这里就要对mvc解析一下
v层由于变动频繁，而又非服务端程序员必理层，故此完全可以独立出来，以配置方式分发。
m层是数据层，那就单纯处理数据就得了，不要添加其他没必要的处理，导致混乱。
c层是调度层，对用户传递过来的url作对应处理，这里跟权限有关，登陆和没登陆的操作。
那么这里少了一层，就是逻辑层logic。建议添加l层
l层处理逻辑，提供服务，提供关闭和开放的决定。
而验证建议使用c层的权限判断，而权限判断是一个服务，让l层提供。
这样设计的好处不少
v层对外，只提供配置文件，让有关程序员，只配置文件即可。
其次m层可以独立出来一个专用服务器，也可安排专门处理这块的程序员负责。
c层处理用户调度，掌握业务层和用户体验的程序员最适合。
l层实际就是服务层，链接业务层和数据层，版本控制，启用和关闭服务。
对新来的同事，验证服务有问题，可以让他重写一个验证服务，不必重写原来的验证的服务。这种修改方式，应该是养成习惯，不修改，只增加。
对于楼主要解决的验证写在controller还是model里，这个问题，取决于架构问题。
如果就是mvc，那么是否有不同角色权限，如果不是，可以选择新建一个基础c，里面配置一个用户验证。如果有不同角色权限，完全可以继承这个基础c，重写即可。
建议在c层验证，个人认为，用户进来，进入调度范围，就必须要正确到达目的地，否则，我不知道调度的作用为何。
如果没有设计缺陷，就放在c层验证吧，概念更清晰一些。
c层验证，l层逻辑
钢铁同志的咆哮
answered 10 years, 10 months ago
你这个问题有挂 laravel 标签, 请问是用这个框架么, 若是, 你可以使用 event 来实现, 例如:
你新建一个 event.php(如何自动加载呢???), 示例代码:
Event::listen('eloquent.saving: User', function($model){
这里做验证, 附加操作逻辑等, 最后 return $model 就好
});
以上代码在调用内置 org, 如 User::save(), 会自动触发.
其中是 saving可以换成creating, created, updating, updated, deleting, deleted, saving, saved, restoring, restored, auth.attempt, auth.login, auth.logout
keylito
answered 10 years, 10 months ago
不是写在controller里面写 controller就是一个分发url的
验证一般写在model里面
大的项目 model都分层了 model获取中立的数据 如果很复杂的话 model也要分层 用户相关逻辑 可以放在 logic层
然后还可以建立一个service层 一些基本的服务是写在service层里面 service层对应的是驱动层 驱动层比如支付驱动 有支付宝 财付通 网银 等等 然后支付服务就是来链接这些支付驱动的 其实有点类似工厂+策略模式
然后 action执行动作前后 还可以Behavior行为层 定义每个执行动作前后处理的一些事情 比如说写入日志什么的
还有更多的 Widget层等等
newday
answered 10 years, 10 months ago
楼上各位的回答很受教 在这也说说自己的看法
我习惯于两者里面都加验证，但验证不尽相同。
model里的验证不要考虑其他层，只做自己要实现的功能所要求的必须验证；
controller里的验证同样不考虑model层，对自己关心的参数进行验证。
model可能会被多个业务调用，也可能被对个程序员写的代码调用，所以不该去考虑上层提供给自己的保护，把自己保护好就行了。
controller层也类似，下面的model层不是一对一为其服务的，所以不该把自己的验证逻辑推给下面。还是那话，如果半年后一个新接手的程序员，谁知道该为其他业务保留那些验证，这链接太不明显了。
好吧 我的承认我是个很保守等程序员 我承认的安全圈是不跨层的
DDD49
answered 10 years, 10 months ago
我们团队用的Java，现在的验证方法是这样的：
比如
User
， 使用各种
JSR303
在实体上搞好校验规则和校验message，封装好
check
方法（这个是最基础的，不管怎么样都需要验证的，一般我们使用的是Hibernate-Validator实现），如果类型和逻辑比较多，还可以衍生出
updateCheck()
,
saveCheck()
，如果校验没有通过就抛出参数错误异常;我在做的过程中其实想到这一点没有必要另外些check方法，完全可以使用JSR303的group分组来实现不同业务的需求验证(这点没有具体实践，只是现在有这么一个想法)
然后在controller那里注解调用对应的check方法作为验证就行了，验证方法如果抛出异常了，直接在catch里面做相应的处理返回.
KbsorD
answered 10 years, 10 months ago