type
status
date
urlname
summary
tags
category
icon
password
catalog
sort
前言
最近项目上要求升级一个工具包
hutool的版本，以解决安全漏洞问题，这不升级还好，一升级反而捅出了更大的篓子，究竟是怎么回事呢？事件回顾
我们项目原先使用的
hutool版本是5.7.2，在代码中，我们的数据传输对象DTO和数据实体对象中大量使用了工具包中的BeanUtil.copyProperties(), 大体代码如下：- 数据传输对象
- 数据实体对象
- 业务逻辑
升级前，
hutool是5.7.2版本下，执行结果如下图。BeanUtil.copyProperties虽然字段类型不一样，但是做了兼容处理，所以业务没有影响业务逻辑。
升级后，
hutool是5.8.8版本，执行结果如下图所示：- 执行报错，因为升级后的版本修改了实现，增加了下面的逻辑，如果包含E, 就会抛错，从而影响了业务逻辑，同时这个id是否包含e又是随机因素，到了生产才发现，就悲剧了。
分析探讨
我发现大部分人写代码都喜欢偷懒，在上面的场景中，虽然
BeanUtil.copyProperties用的一时爽，但有时候带来的后果是很严重的，所以很不推荐这种方式。为什么这么说呢？比如团队中的某些人偷偷改了数据传输对象DTO，比如修改了类型、删去了某个字段。用
BeanUtil.copyProperties的方式压根无法在编译阶段发现，更别提修改的影响范围了，这就只能把风险暴露到生产上去了。那有什么更好的方法呢？推荐方案
- 原始的
get、set方式
我是比较推崇这种做法的，比如现在
DiagramDTO删去某个字段，编译器就会报错，就会引起你的注意了，让问题提前暴露，无处遁形。你可能觉得站着说话不腰疼，字段少好，如果字段很多还不得写死啊，我这里推荐一个IDEA的插件，可以帮你智能生成这样的代码。
话不多说，自己玩儿去~~
- 使用开源库
ModelMapper
ModelMapper是一个开源库，可以很方便、简单地将对象从一种类型映射到另一种类型，底层是通过反射来自动确定对象之间的映射，还可以自定义映射规则。- 使用开源库
MapStruct
MapStruct也是Java中另外一个用于映射对象很流行的开源工具。它是在编译阶段生成对应的映射代码，相对于ModelMapper底层放射的方案，性能更好。DiagramMapper接口使用了@Mapper注解，用来表明使用MapStruct处理
MapStruct中更多高级特性大家自己探索一下。
总结
小结一下，对象在不同层之间进行转换映射，很不建议使用
BeanUtil.copyProperties这种方式，更加推荐使用原生的set, get方式，不容易出错。当然这不是将BeanUtil.copyProperties一棒子打死，毫无用武之地，在特定场景，比如方法内部对象的转换等影响小的范围还是很方便的。- 作者:Honesty
- 链接:https://blog.hehouhui.cn/archives/hutool-beanutil-error
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章