| 看了这部分代码以后,你可能会问,那逆向转化会有什么用呢?其实我们有很多小的业务需求中,入参和出参是一样的,那么我们变可以轻松的进行转化,我将上边所提到的  UserInputDTO 和 UserOutputDTO 都转成 UserDTO 展示给大家。 DTO: public class UserDTO {  private String username;  private int age;  public String getUsername() {  return username;  }  public void setUsername(String username) {  this.username = username;  }  public int getAge() {  return age;  }  public void setAge(int age) {  this.age = age;  }  public User convertToUser(){  UserDTOConvert userDTOConvert = new UserDTOConvert();  User convert = userDTOConvert.convert(this);  return convert;  }  public UserDTO convertFor(User user){  UserDTOConvert userDTOConvert = new UserDTOConvert();  UserDTO convert = userDTOConvert.reverse().convert(user);  return convert;  }  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) {  UserDTO userDTO = new UserDTO();  BeanUtils.copyProperties(user,userDTO);  return userDTO;  }  } } 
 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 实现,我觉得目前仍然是很优秀的,具体如何使用,我不想讲,因为谷歌上你可以搜索出很多答案! (编辑:鹰潭站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |