Java的数据判断放在Service层还是Controller层好一点？

Posted 2023-02-27

最近公司新开一个项目，在写代码的时候发生了一下歧义。
对于在Dao查询到的数据放到Service层判断以及封道返回数据里返回到Controller好还是把这些判断放到Controller里好
我是放到Service判断返回的，但是有同事不认可
这是我的Controller代码
@RequestMapping(value = "/updateRoleByID", method = RequestMethod.POST)
@ResponseBody
public Object updateRoleByID(MdCfSysUserRole roleEdit)
ResultData<Object> result = roleTreeService.updateRoleByID(roleEdit);
return result;


这是我的Service代码
@Override
public ResultData<Object> updateRoleByID(MdCfSysUserRole roleEdit)
if(null != roleEdit && !"".equals(roleEdit.getFid().toString().trim()))
int editRoleNum = roleDao.updateRoleByID(roleEdit);
return operatingSuccesNum(editRoleNum);
else
return result;


public static ResultData operatingSuccesNum(int numm)
ResultData resultData = new ResultData();
if (numm > 0)
resultData.setCode(1);
resultData.setMessage("操作成功");
resultData.setStatus("Success");
return resultData;
else
return resultData;

关于MVC架构中最有歧义的一点应该就是你提到的数据验证应该放在哪一层这点了。
1、你要知道，开发模式只是建议，而不是必须，所以只要能够说得出道理，能得到众多人认可的编码方式，都是合理的，并不存在绝对的对错。所以，从这个角度你可以先理解一下你同事说的理由是什么。
2、从我个人来说，我是把验证分成两块看的：
1）规范性验证
比如，数字格式、字符长度，事实上，这些验证本身在ui端已经进行过一次，但为了保证程序的健壮性（防止有人直接通过模拟浏览器方式访问），在后台仍然应该验证，这类验证是直接在controller层的。
其实，这个不需要我们自己写，在springboot之类的框架里提供了大量的注解用来确保传入参数的规范性，也从一个侧面证明了，这类验证放在controller层已经得到了普遍的认可。
2）业务性验证
这类验证普遍需要进行数据库或其他后台操作，如用户名重复验证。这类验证必然是写在service层的，只是究竟是作为业务方法的组成部分还是特别提供一个controller接口来返回调用结果，是由业务需求定的。
3、结论
能写在controller层的验证（即无需调用dao层代码）都写在controller（因为实际上你在ui已经写过了，此时你完全没必要再把它当成一个“业务”来对待），不能的，写在service层（但是最好是作为一个独立的方法存在，而不是放在service的业务方法里作为一段代码存在） 参考技术A 看你们项目经理的，遵从你们项目经理的同意规范，而且你们这个有问题吧 没有添加事物，

我们公司的话都是在service写，然后把事物添加到service层，毕竟很多的时候用户一个操作不是一个改查库就可以完成的，比如保存一个人的信息，需要保存个人信息和他的权限信息，需要在两个表中加数据，事物加到service层，向A表中插入数据然后判断，失败退出回滚事物，在向B中添加数据然后判断，失败退出回滚事物， 如果不这么弄得话就可能出现A插入成功了B失败了事物没有回滚导致数据错误