前言
BeanUtils.copyProperties十有八九是你这些年工作中用的很多的其中一个,不管是Apache的还是Spring的。
网上的解释浩如烟海,我这边用一个超简单的例子直观展示给你看。
以后就记住了,能不用就不用。
正文
1、网上的解释
我收纳了几个网上最典型的解释,也就是这个工具类的缺点,可以先回顾一下。
大致如下:
1、只能浅拷贝,简单理解就是只复制的引用,没复制对象内容;
2、名称和类型要匹配,不匹配的属性会复制失败;
3、性能一般,因为用了反射机制。
这里面,其实对于我们来讲,这个工具好不好用,理解第2点就足够了。
2、名称不匹配
假设一个user对象,有个属性是手机号,那么我们看看使用BeanUtils后是什么效果。
这是原对象,定义联系方式是telePhone。
然后我们定义一个接收拷贝的对象
使用BeanUtils.copyProperties拷贝后效果如下:
可以看到,因为名称少了一个字母,所以拷贝后联系方式是null。
如果是返回给前端的接口数据,字段又多,这样的问题会耽误你不少时间。
3、类型不匹配
我们再换个测试方式,原对象有个age属性是String类型。
而接收拷贝的对象,因为你的同事偷懒,误以为不是String,就给个Integer类型。
看看效果,不会报错。
但是age也是null,没有复制成功。
4、如果遇到猪队友
其实上面两个就是典型的缺点了,那我们如果再极端点,假设你某天遇到了猪队友。
你们有一个类型是金额,原对象类型是BigDecimal。
而猪队友自己创建了一个VO,给你来个double类型,你觉得会报错吗?
假如这个金额传的还挺大
看下效果
玛德,直接钱没了,你完了。
5、我怎么用的
工作这么多年,上面的坑我基本都踩过,有些是我踩别人的。
所以我挺早就开始像下面这么用了,返璞归真了。
没错,直接用IDEA的插件自动生成setter,然后写值。
什么BeanUtils,什么MapStruct,什么ModelMapper,都再见!
灵活,可控,直观,性能还好,字段多也多不到哪里去,中小企业的最佳选择。
总结
我所在的互联网公司,从前年开始就已经禁止使用BeanUtils.copyProperties了,因为坑了太多队友。
有段时间也有项目用MapStruct,但是当映射变得复杂时,配置也相应复杂起来,而且错误信息有时会不清晰。
所以最终我们还是返璞归真了,用插件简化映射,人工赋值,降低维护难度,已被列入了公司的编程规范。
君子,不立于危墙之下,看得见摸得着的心里才踏实。
喜欢就点赞关注↓↓↓,更多干货持续输出。