腾讯工作近十年大佬：不是我打击你！你可能真的不会写Java

API：

@PostMapping 
 public UserDTO addUser(UserDTO userDTO){ 
 User user = userDTO.convertToUser(); 
 User saveResultUser = userService.addUser(user); 
 UserDTO result = userDTO.convertFor(saveResultUser); 
 return result; 
 } 

当然，上述只是表明了转化方向的正向或逆向，很多业务需求的出参和入参的 DTO 对象是不同的，那么你需要更明显的告诉程序：逆向是无法调用的：

private static class UserDTOConvert extends Converter<UserDTO, User> { 
 @Override 
 protected User doForward(UserDTO userDTO) { 
 User user = new User(); 
 BeanUtils.copyProperties(userDTO,user); 
 return user; 
 } 
 @Override 
 protected UserDTO doBackward(User user) { 
 throw new AssertionError("不支持逆向转化方法!"); 
 } 
 } 

看一下 doBackward 方法，直接抛出了一个断言异常，而不是业务异常，这段代码告诉代码的调用者，这个方法不是准你调用的，如果你调用，我就”断言”你调用错误了。

关于异常处理的更详细介绍，可以参考我之前的文章：如何优雅的设计 Java 异常(http://lrwinx.github.io/2016/04/28/%E5%A6%82%E4%BD%95%E4%BC%98%E9%9B%85%E7%9A%84%E8%AE%BE%E8%AE%A1java%E5%BC%82%E5%B8%B8/) ，应该可以帮你更好的理解异常。

bean 的验证

如果你认为我上边写的那个添加用户 API 写的已经非常完美了，那只能说明你还不是一个优秀的程序员。我们应该保证任何数据的入参到方法体内都是合法的。

为什么要验证

很多人会告诉我，如果这些 API 是提供给前端进行调用的，前端都会进行验证啊，你为什还要验证?

其实答案是这样的，我从不相信任何调用我 API 或者方法的人，比如前端验证失败了，或者某些人通过一些特殊的渠道(比如 Charles 进行抓包)，直接将数据传入到我的 API，那我仍然进行正常的业务逻辑处理，那么就有可能产生脏数据!

“对于脏数据的产生一定是致命”，这句话希望大家牢记在心，再小的脏数据也有可能让你找几个通宵!

jsr 303验证

hibernate 提供的 jsr 303 实现，我觉得目前仍然是很优秀的，具体如何使用，我不想讲，因为谷歌上你可以搜索出很多答案!

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!