看了这部分代码以后,你可能会问,那逆向转化会有什么用呢?其实我们有很多小的业务需求中,入参和出参是一样的,那么我们变可以轻松的进行转化,我将上边所提到的 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 实现,我觉得目前仍然是很优秀的,具体如何使用,我不想讲,因为谷歌上你可以搜索出很多答案!
(编辑:ASP站长网)
|