大佬们, 请教一下关于 Java 后端 Service 层

为什不问问神奇 gpt 呢

我是加的，要防着同事一手

public 方法, 对传入参数要做防御性判断, 并打印 log.
看你代码, 好像这两个都没做, 这在大厂恐怕不能通过 review.

上线出问题你都不知道是不是你代码自己的问题, 还是别人传入参数的问题.

@wxw752 大佬, 如果加上校验, 返回什么比较合适呢, 错误提示嘛
/**
* 批量删除角色员工关系
*
* @param roleEmployeeUpdateForm
* @return
*/
public ResponseDTO<String> batchDeleteRoleEmployee(RoleEmployeeUpdateForm roleEmployeeUpdateForm) {
if (roleEmployeeUpdateForm.getRoleId() == null || CollectionUtils.isEmpty(roleEmployeeUpdateForm.getEmployeeIdList())) {
ResponseDTO.error(UserErrorCode.PARAM_ERROR, "参数错误");
}
roleEmployeeDao.batchDeleteRoleEmployee(roleEmployeeUpdateForm.getRoleId(), roleEmployeeUpdateForm.getEmployeeIdList());
return ResponseDTO.ok();
} 类似这样嘛

@vuevue 问了, 但是很多场景不太理解, 有些也是看情况而定

@iintothewind 感谢大佬, 看来还是要考虑各个方面问题

看上下文以及自己需求, 如果允许代码 break, 就抛 exception,
如果还有返回那就自己 handle, 返回约定的结果,
但重要是的是打印 log, 防止扯皮,
在大厂, 上线非常重要的是打印 log, 要不然你自己说不清楚, 出问题, 锅就是你的.

@iintothewind 日志的话, 一般打印错误日志和成功日志嘛, 如果发生异常有全局异常处理类做日志打印, service 层还需要打印吗

@iintothewind 好的, 感谢感谢

你这个真的受 spring 影响太深了, 你还指望全局 handler 给你兜着啊?

那 Error Handling 得做的多糟糕才跑到做全局 handling,
所谓的全局 error handling 难道不是就打印一下啥都不做吗? 跑那去你业务代码上下文早没了, 你还能看到啥啊?


public 方法, 入口参数肯定要打印 log 的, 成功和失败看情况啊, 失败的上下文 log 更重要.

@iintothewind 明白了, 日志是不是一般在 service 层打印, 感觉 controller 好像打印入口参数好像更准确, 可是我最近在学习一个开源项目(SmartAdmin)
看他们规范说 controller 层
1. 不做任何的业务逻辑操作
2. 不做任何的参数、业务校验，参数校验只允许使用 @Valid 注解做简单的校验
3. 不做任何的数据组合、拼装、赋值等操作
4. 只能在 controller 层获取当前请求用户，并传递给 service 层。

主要为了学习代码编码风格和规范, 看哪些开源项目比较好啊, 或者看什么别的东西

目前看的是 SmartAdmin 这个开源项目学习, 大佬有了解的嘛, 看哪位作者的风格比较好呢, 若依实在不喜欢, 目前觉得这个 SmartAdmin 对我帮助很大

我不知道, 反正学习打 log 在大厂爬屎山第一课, 出了不要暴露 PII 信息之外, 没有什么不能打的, 毕竟是为了防止自己背锅的.
其它的我不知道, 代码风格每个团队不同, 没有对错, 你有话语权你就能决定团队该用什么风格, 你没有你听别人的, 都一样怕屎山, 没有什么高低之分.

@iintothewind 好的 感谢您