欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  后端开发

验证写在controller还是model里?

程序员文章站 2024-01-17 10:08:16
...
之前团队留下的模型代码都是这样的:
public function getcount($where){//$where是数组,严格对应DB字段!
   if(!empty($where)){
    $db->where($where);
   }
   $db->from($tablename);
   return $db->count_all_results(); 
}

public function edit($tid,$data){//$data是数组,严格对应DB字段!
  $db->where('tid', $tid);
  return $db->update($tablename, $data);
}

当我在控制器里调用MODEL的时候,要严格按照数据库schema来拼装参数。

MODEL里这样写这样的纯粹的增删改查有什么优点?
验证部分究竟应该放在哪里比较好
请阐明其中的道理和厉害关系。

之前可能有人看的太快导致的误解,上述代码的model里面那个empty并不算真的判断,关于$where参数,是需要严格按照数据库对应的字段拼装,而model里并没有任何判断,严重依赖控制器喂给它正确的参数。

项目经理铁定要求在控制器处理验证,所以现在的控制器里有数量可观的巨型函数(需要调用model的地方都超过150行了),而且格式基本近似。

举个例子,现在的情况是:
view提交表单到controller,在那里验证表单,呼叫model,并为model拼装数组参数(如同上面代码里那样)。

看到后来新的答案里有些说的情况比较模糊,比如“复杂逻辑”这样还是没法明确。所以,我再细化一下问题:

现在的model里仅仅是转发了一下sql的增删改查的基本操作,在控制器里调用这些model的时候,我必须严格根据数据库里的字段名来拼装$data数组,这就基本等同于没有model,还不如控制器里直接拼sql算了。

回复内容:

之前团队留下的模型代码都是这样的:

public function getcount($where){//$where是数组,严格对应DB字段!
   if(!empty($where)){
    $db->where($where);
   }
   $db->from($tablename);
   return $db->count_all_results(); 
}

public function edit($tid,$data){//$data是数组,严格对应DB字段!
  $db->where('tid', $tid);
  return $db->update($tablename, $data);
}

当我在控制器里调用MODEL的时候,要严格按照数据库schema来拼装参数。

MODEL里这样写这样的纯粹的增删改查有什么优点?
验证部分究竟应该放在哪里比较好
请阐明其中的道理和厉害关系。

之前可能有人看的太快导致的误解,上述代码的model里面那个empty并不算真的判断,关于$where参数,是需要严格按照数据库对应的字段拼装,而model里并没有任何判断,严重依赖控制器喂给它正确的参数。

项目经理铁定要求在控制器处理验证,所以现在的控制器里有数量可观的巨型函数(需要调用model的地方都超过150行了),而且格式基本近似。

举个例子,现在的情况是:
view提交表单到controller,在那里验证表单,呼叫model,并为model拼装数组参数(如同上面代码里那样)。

看到后来新的答案里有些说的情况比较模糊,比如“复杂逻辑”这样还是没法明确。所以,我再细化一下问题:

现在的model里仅仅是转发了一下sql的增删改查的基本操作,在控制器里调用这些model的时候,我必须严格根据数据库里的字段名来拼装$data数组,这就基本等同于没有model,还不如控制器里直接拼sql算了。

不是写在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里实体对象之间的耦合度,复用性降低。

验证写在model里面会比较好。
如果你写在controller里,如果另外一个controller也需要用到相同的验证,怎么办?还得复制粘贴相同的代码,复用性就没有体现出来了,如果你写在model里面那就不一样了。

楼上各位的回答很受教 在这也说说自己的看法
我习惯于两者里面都加验证,但验证不尽相同。
    model里的验证不要考虑其他层,只做自己要实现的功能所要求的必须验证;
    controller里的验证同样不考虑model层,对自己关心的参数进行验证。
model可能会被多个业务调用,也可能被对个程序员写的代码调用,所以不该去考虑上层提供给自己的保护,把自己保护好就行了。
controller层也类似,下面的model层不是一对一为其服务的,所以不该把自己的验证逻辑推给下面。还是那话,如果半年后一个新接手的程序员,谁知道该为其他业务保留那些验证,这链接太不明显了。
好吧 我的承认我是个很保守等程序员 我承认的安全圈是不跨层的

我们团队用的Java,现在的验证方法是这样的:
比如User, 使用各种JSR303在实体上搞好校验规则和校验message,封装好check方法(这个是最基础的,不管怎么样都需要验证的,一般我们使用的是Hibernate-Validator实现),如果类型和逻辑比较多,还可以衍生出updateCheck(),saveCheck() ,如果校验没有通过就抛出参数错误异常;我在做的过程中其实想到这一点没有必要另外些check方法,完全可以使用JSR303的group分组来实现不同业务的需求验证(这点没有具体实践,只是现在有这么一个想法)
然后在controller那里注解调用对应的check方法作为验证就行了,验证方法如果抛出异常了,直接在catch里面做相应的处理返回.

model里处理复杂的逻辑,controller里处理交互控制转发。这是基本的MVC模式吧,要说好处大概就是逻辑处理与输入输出相互分开

表单验证等没有通用性的验证建议放在controller,一些复杂和通用的业务逻辑建议下沉到model层去实现。

model变化的频率和验证变化的频率差别太大,就此一点就注定他们不能在一起

这个是不是只针对php, java 为什么在struts里有 validate 方法, Bean 里面只有 get set 方法

需要分别处理,不能单单说是写在controller还是model,根据业务需求的不同经常会对验证做区别处理,model建议只做些基本的数据合法性验证

写在module是没有问题的,但是这里边涉及一个有意思的问题,就是如何将校验结果反馈回来。

如果在module层做非常详细的错误报告,也是比较繁琐,而且可能会增加一些开销。而反馈的结果还需要反馈到controller,最后反映到view上。另一方面module也可能被程序直接创建修改,这时候的验证并不需要细粒度,只需要一个布尔就够了。

所以一般我比较倾向于用一个简单逻辑的module验证,在controller中做错误报告的生成。

看框架,大一点框架的Model封装的比较好。
可以把一些逻辑写在Model里面。

一般项目,建议独立出来把逻辑,权限验证等信息放在Logic里面。

你这个问题有挂 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

其实可在Controller和Model之间设置一个业务逻辑层,该层负责处理输入到数据录入的处理,一切业务参数验证及组装都可以交给业务办,这样即可,另外不同层处理不同事物,比如接受参数的HTTP层、路由层,都是可以加东西的,各层分而治之,没必要都给controller了,controller是中介,衔接作用,大而全就显得代码结构不清晰,降低了可维护性。

验证代码应该写在服务层
那么这里就要对mvc解析一下

v层由于变动频繁,而又非服务端程序员必理层,故此完全可以独立出来,以配置方式分发。
m层是数据层,那就单纯处理数据就得了,不要添加其他没必要的处理,导致混乱。
c层是调度层,对用户传递过来的url作对应处理,这里跟权限有关,登陆和没登陆的操作。
那么这里少了一层,就是逻辑层logic。建议添加l层
l层处理逻辑,提供服务,提供关闭和开放的决定。

而验证建议使用c层的权限判断,而权限判断是一个服务,让l层提供。

这样设计的好处不少

v层对外,只提供配置文件,让有关程序员,只配置文件即可。
其次m层可以独立出来一个专用服务器,也可安排专门处理这块的程序员负责。
c层处理用户调度,掌握业务层和用户体验的程序员最适合。
l层实际就是服务层,链接业务层和数据层,版本控制,启用和关闭服务。

对新来的同事,验证服务有问题,可以让他重写一个验证服务,不必重写原来的验证的服务。这种修改方式,应该是养成习惯,不修改,只增加。

对于楼主要解决的验证写在controller还是model里,这个问题,取决于架构问题。
如果就是mvc,那么是否有不同角色权限,如果不是,可以选择新建一个基础c,里面配置一个用户验证。如果有不同角色权限,完全可以继承这个基础c,重写即可。
建议在c层验证,个人认为,用户进来,进入调度范围,就必须要正确到达目的地,否则,我不知道调度的作用为何。
如果没有设计缺陷,就放在c层验证吧,概念更清晰一些。
c层验证,l层逻辑

我们团队在使用MVC框架时, 都会独立一层Behavior出来, 这一层放业务逻辑.
如果是数据本身进存储的时候需要验证, 那么就在model层做.
如果是因为业务逻辑需要验证, 那么就在behavior层做.例如订单状态的流转,验证非法的状态流转.
如果是和业务逻辑无关的(从controller层转发数据), 那么就在controller层做.
v层由前端或者客户端自行验证,
这样的好处是, behavior可以作为通用逻辑, 让controller有不同的展现方式.特别方便既有web也有接口功能的程序. 坏处是, 需求改动较大的时候, 需要对业务逻辑非常清晰

倾向于 view - model - behavior - controller,
数据本身进存储的时候需要验证 MODEL
业务逻辑需要验证 BEHAVIOR
和业务逻辑无关的 CONTROLLER

权限验证放到 controller
数据验证放到 model