不知道从什么时候开始,大家对Spring的BeanUtils.copyProperties口诛笔伐,似乎用了这个方法拷贝bean属性就低人一等,代码分分钟就是一堆bug一样。但我相信,这个方法在大家的项目中出场率一定不低。
今天我们来分析一下,BeanUtils.copyProperties那些常被人吐槽的点,是否真的有大家说的那么不堪。
槽点1. 不声明属性的get、set方法,属性将copy失败
首先我们要明白,BeanUtils.copyProperties中sourceBean和targetBean的属性的拷贝,是通过反射中的Method完成的,所以如果Bean不声明属性的set和get方法,就不能进行属性间的copy。
所以说这不能说人家框架有问题,就像我们如果不了解Springweb的原理,写出的接口出了问题,却说Spring框架有问题,岂不是欲加之罪?
槽点2. copy为浅拷贝(拷贝对象的引用)
BeanUtils.copyProperties的定位就是快速浅拷贝,对于大多数的场景而言,通过getset方式快速复制属性,已经基本能满足我们的日常需求。如果有深拷贝的需求,那我们要做的应该更换拷贝工具,而不是埋怨BeanUtils.copyProperties有bug。
槽点3. Spring不同版本对属性泛型处理方式不同
从工具类的角度看,两个类的属性名相同,但是泛型类型不同,所以未进行属性复制。
这个问题从不同的角度看似乎都有其合理性。从用户角度看,同一个名称的属性未复制值,这是个bug。但是从工具类角度看,不同的泛型就相当于两个属性,不复制是合理的。
但是反过来想,如果工具类直接把属性名相同的值进行复制,而不校验泛型,那么当我们使用target的时候,发现获取的值不是source中的类型,是不是又该埋怨工具类擅自做主了呢?
所以我觉得,这个问题顶多算是写代码不规范导致的。
性能
对于绝大部分场景来说,属性复制不会对性能有特别大的影响,一般不会成为性能瓶颈。
总结
说了这么多,其实也并不是要大家无脑的去使用BeanUtils.copyProperties,而是希望大家在合适的场景选用合适的工具做合适的事。
我们常说,透过现象看本质,能真正的理解其背后的复制原理,才能让我们的编码能力不断提升,而不是人云亦云的说某某工具类不好用。
借用一位老哥的话:有的人干5年有5年的经验,有的人一个经验用5年。希望大家都能像前者一样,在技术的道路不断进步。