我也造了个轮子:BeanMapping(属性拷贝)

背景  

  最近公司在大力推进服务化平台，我在中间主要做一个orm框架，解决model和数据源之间的映射问题。这里不选择已有的hibrenate，主要考虑自己公司的一些特殊场景：比如多数据源(数据库，搜索引擎，memcached，nosql等)，同时可以 做一些特殊优化，比如多数据源加载时采用并行加载(我之间做的一个工具包 (业务层)异步并行加载技术分析和设计)

 也不多罗嗦，我主要负责从多个数据源搜集回来的数据，构造成对应的model对象。可以看一下具体的分析过程。

 

分析

   每个数据源采集回来的数据可能比较凌乱，有map对象，POJO对象，至于这个映射过程。因为是在老系统上实施，以前都没有service的概念，在数据库的设计会很比较乱，都是来一个需求加几个字段的那一类型。 所以具体data -> model对象的映射过程，就需要额外考虑一些特殊功能。

 

需求整理： 

1. 处理的data是个map对象
2. 处理的data是个pojo bean
3. 映射过程中，处理的data属性名和目标对象model的属性会大不相同
4. 映射过程中，data中的数据大多都是文本型，而对应的model会是根据业务场景定义的强类型，需要有类型转化
5. 对应的data可能是一个平面型的map/bean对象，需要转化有层次结构，带立体的模型。比如model里包含一些子model等
6. 需要处理特殊情况，比如data中有个属性是个json格式数据，需要在解析后再转化到某几个model属性上

针对这些需求，回过头看一下现在比较流行的几个处理工具包： cglib , beanutils 。 

cglib(之间的一篇分享文档： cglib源码学习交流) : 素以性能著称，主要是BeanCopier，但功能很简单。主要是解决bean之间，同名属性的转化，功能无法满足

beanutils :  功能上支持到是还不错，可以支持处理map,pojo的转化，不同属性类型之间的转化，也可以支持nested子模型的映射。 但无法解决不同名属性之间的映射，json格式类似数据的处理，还有一个就是性能不咋的。根据原先的测试来看，应该是cglib性能的1/1000，相差了3个数量级。

基于如上的需求，以及对现有产品的优缺点分析，所以最后决定我要造一个轮子，刚开始其实还是本着完成项目。但后来发觉写着写着，越来越像那么回事，所以索性剥离了业务部分代码，安心的在底层先实现了一个BeanMapping的轮子。 

设计

  根据上面的需求分析，因为要解决不同属性名自己的映射关系，单纯的依赖bean属性的扫描无法满足。所以需要引入配置文件，定义mapping的映射关系。

 

整体设计示意图： 

说明： 

 

• 将属性mapping的动作抽象成Get / Set两个操作。 Get操作针对数据源对象，Set操作针对数据目标对象
• 在Get/Set中间，定义了一个ValueProcess处理插件的概念，允许扩展相关的功能插件 （自认为相比于BeanUtils/BeanCopier的非常好的亮点，扩展性良好）
  1.  比如默认值
  2.  类型转化器
  3.  json数据处理
  4.  日志记录

Get/Set为整个框架的核心(core)实现，ValueProcess为框架的扩展点，允许自定义一些功能插件，默认已经提供了几个功能处理。

对应的类关系图： 

Get/Set操作类

 

ValueProcess设计类：

客户端使用类设计：

 

 

几个客户端API说明： 

1. BeanMapping :  本轮子的核心功能，通过基于配置方式的mapping映射，支持convetor,defaultValue,script的所有功能。要求使用之前必须提前配置bean-mapping映射。
2. BeanCopy 和 BeanMap ： 都是一些扩展功能，基于本轮子的核心架构不变的基础上，开发了BeanUtils.copyProperties() , BeanUtils.describe,  BeanUtils.populate()的功能。 使用该api，可以不需要配置映射文件，会进行自动扫描，就是基于同名属性的处理前提。
3. BeanMappingUtil ： 提供了BeanMapping , BeanCopy , BeanMap的所有方法，提供静态的util方法处理。每次都会构造对应的BeanMapping等对象，注意：每次进行构造BeanCopy,BeanMap，解析的属性结果会有cache。所以使用该util不会有很明显的性能下降，无非就是多一些临时对象。

最后定义的配置文件示例：  mapping.xml

 

<bean-mappings xmlns="http://mapping4java.googlecode.com/schema/mapping" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://mapping4java.googlecode.com/schema/mapping http://mapping4java.googlecode.com/svn/trunk/src/main/resources/META-INF/mapping.xsd">
    <!--  (bean-bean) mapping 测试 -->
    <bean-mapping batch="true" srcClass="com.agapple.mapping.object.SrcMappingObject" targetClass="com.agapple.mapping.object.TargetMappingObject" reversable="true">
    	<field-mapping srcName="intValue" targetName="intValue" />
    	<field-mapping targetName="integerValue" script="src.intValue + src.integerValue" /> <!-- 测试script -->
    	<field-mapping srcName="start" targetName="start" />
    	<field-mapping srcName="name" targetName="targetName" /> <!--  注意不同名 -->
    	<field-mapping srcName="mapping" targetName="mapping" mapping="true" />
    </bean-mapping>
    
    <bean-mapping batch="true" srcClass="com.agapple.mapping.object.NestedSrcMappingObject" targetClass="com.agapple.mapping.object.NestedTargetMappingObject" reversable="true">
    	<field-mapping srcName="name" targetName="name" defaultValue="ljh" /> <!-- 测试default value -->
    	<field-mapping srcName="bigDecimalValue" targetName="value" targetClass="string" defaultValue="10" /> <!-- 测试不同名+不同类型+default value  -->
    </bean-mapping>

</bean-mappings>

说明：

• bean-mappings :  可以指定xsd，方便编写配置文件。通过IDE可以给于提示
• bean-mapping : 定义需要进行mapping映射的对象信息，需要指定class全路径
  reversable主要表明此mapping动作是可逆的，默认为true。 batch主要是一优化特性，后面再细表。
• field-mapping : 主要定义需要进行映射的属性之间的映射关闭 srcName : 源对象的属性名 srcClass : 源对象的class类型 targetName : 目标对象的属性名 targetClass : 目标对象的class类型 mapping : 表明是否需要进行递归映射，比如这里的，在处理NestedSrcMappingObject和NestedTargetMappingObject时，会递归进行映射处理 defaultValue : 很好理解，就是针对源属性为null时，默认值处理 convetor : 自定义类型转化器 (默认支持基本类型，BigDecimal,BigInteger,Array,List之间的转化处理) script : 高级特性，支持自定义的映射规则，比如这里进行一个+运算。

  targetName="integerValue" script="src.intValue + src.integerValue" 

几点说明： 

1. srcClass/targetClass： 默认可不关注，系统会自动进行识别，在defaultValue和convetor转化处理。 还有一点：如果对象中出现同名的属性时，可以指定targetClass进行唯一定位
2. defaultValue ： 相比于BeanCopier和BeanUtils，一个特有的特性。 大家熟悉ibatis的配置就知道会有一个nullvalue配置，主要是方便客户端处理，避免进行一些无谓的==null/==0这样的处理
3. convetor ： 相比于BeanUtils， 这里允许声明属性之间的转化类，比如你注册了一个alias别名的convetor，就可以在这里声明进行使用，会优先使用你定义的(如果不指定，则会进行自动根据类型进行匹配)。
   自动处理会有个局限性，就是convetor会是全局性。比如你定义了一个String到Date的处理，以后整个jvm中所有的场景都会按照你定义的进行转化，到时候你怎么死自己都不知道
4. script： 系统的高级特性，做为系统的一些扩展点，可以支持一些比较复杂的处理，比如以后的json/xml等处理，只需注册你的functions。比如这里定义： script="src.intValue + src.integerValue"。

使用例子

BeanMapping列子： BeanMappingTest.java

public BeanMapping srcMapping    = BeanMapping.create(SrcMappingObject.class, TargetMappingObject.class);
public BeanMapping targetMapping = BeanMapping.create(TargetMappingObject.class , SrcMappingObject.class);

@Test
public void testBeanToBean_ok() {
	SrcMappingObject srcRef = new SrcMappingObject();
	srcRef.setIntegerValue(1);
	srcRef.setIntValue(1);
	srcRef.setName("ljh");
	srcRef.setStart(true);

	TargetMappingObject targetRef = new TargetMappingObject();// 测试一下mapping到一个Object对象
	srcMapping.mapping(srcRef, targetRef);

	SrcMappingObject newSrcRef = new SrcMappingObject();// 反过来再mapping一次
	targetMapping.mapping(targetRef, newSrcRef);
}

 

BeanCopy例子： (发觉和BeanCopier使用比较像)  BeanCopyTest.java

public BeanCopy srcCopyer    = BeanCopy.create(SrcMappingObject.class, TargetMappingObject.class);
public BeanCopy targetCopyer = BeanCopy.create(TargetMappingObject.class , SrcMappingObject.class);

@Test
public void testCopy_ok() {
	SrcMappingObject srcRef = new SrcMappingObject();
	srcRef.setIntegerValue(1);
	srcRef.setIntValue(1);
	srcRef.setName("ljh");
	srcRef.setStart(true);

	TargetMappingObject targetRef = new TargetMappingObject();// 测试一下mapping到一个Object对象
	srcCopyer.copy(srcRef, targetRef);

	SrcMappingObject newSrcRef = new SrcMappingObject();// 反过来再mapping一次
	targetCopyer.copy(targetRef, newSrcRef);
}

 

BeanMap例子： (支持bean<->map的转化处理) BeanMapTest.java

public BeanMap beanMap = BeanMap.create(SrcMappingObject.class);

    @Test
    public void testDescribe_Populate_ok() {
        SrcMappingObject srcRef = new SrcMappingObject();
        srcRef.setIntegerValue(1);
        srcRef.setIntValue(1);
        srcRef.setName("ljh");
        srcRef.setStart(true);

        NestedSrcMappingObject nestedSrcRef = new NestedSrcMappingObject();
        nestedSrcRef.setBigDecimalValue(BigDecimal.ONE);
        srcRef.setMapping(nestedSrcRef);

        Map map = beanMap.describe(srcRef);

        SrcMappingObject newSrcRef = new SrcMappingObject();// 反过来再mapping一次
        beanMap.populate(newSrcRef, map); // 从map属性设置到bean
    }

性能测试数据

不过前面功能说的如何天花乱坠，整个工具的性能相比也是大家比较会关注的一个点。 我这里大致做了下测试：构造一个CopyBean，基本涵盖了普通类型，对象处理等，进行批量处理

CopyBean : 

 

public class CopyBean {

        private int        intValue;
        private boolean    boolValue;
        private float      floatValue;
        private double     doubleValue;
        private long       longValue;
        private char       charValue;
        private byte       byteValue;
        private short      shortValue;
        private Integer    integerValue;
        private Boolean    boolObjValue;
        private Float      floatObjValue;
        private Double     doubleObjValue;
        private Long       longObjValue;
        private Short      shortObjValue;
        private Byte       byteObjValue;
        private BigInteger bigIntegerValue;
        private BigDecimal bigDecimalValue;
        private String     stringValue;
}

BeanCopy性能测试

对比的内容：

• BeanCopy.copy 
• BeanCopy.simpleCopy (不做类型转化)
• Method.invoke
• FastMethod.invoke 
• BulkBean
• BeanCopier
• HardCode (硬编码，直接手工挨个复制属性)
• PropertyUtils  (不做类型转化)
• BeanUtils

说明： 因为beanUtils，PropertyUtils的性能太差，基本上其他的柱状图都看不清楚。

说明： 排除了PropertyUtils/BeanUtils的性能对比图，发现BeanMapping提供的copy方法可以比直接Method的反射调用略快一点，不过和cglib的BeanCopier还是有点差距，毕竟人家的功能支持的也很简单，很裸露的get/set调用。性能上基本也和直接硬编码写copy操作一样。

具体测试数据：

	开启batch优化(200w次):单位ns	纯解释执行(排除JIT优化)(10w次):单位ns
BeanMapping.copy	1189	72780
BeanMapping.simpleCopy	1178	69381
Method	1322	25882
FastMethod	533	15961
BulkBean	108	4420
BeanCopier	18	1566
HardCopy	17	1376
PropertyUtils	22143	1037770
BeanUtils	43980	1766392

说明：

• 首先注意一下，单位是ns。　1s = 1000ms = 1 * 10^9 ns
• BeanCopier和手工编码写的copy性能基本接近
• BeanMapping的copy和simpleCopy的区别，copy可以支持类型转化，simpleCopy不会处理类型转化。
• BeanMapping的性能是BeanUtils的近40倍左右，不过和BeanCopier还是有些差距，大概在50倍左右。 (换另一个概念，就是执行100w次，BeanCopier可以比BeanMapping节省1秒，可以比BeanUtils节省40多秒，比较直观吧)

最后

　整个过程，完成功能代码大概只花了一周的时间，但是代码的重构/抽取，性能优化花了我近２周的时间。性能从最初的比BeanUtils慢，逐步的提升到了快几十倍，还是比较有成就感的。

 

还有一点，就是自己比较满意ValueProcess概念的设计，相比于BeanCopier或者BeanUtils扩展性好多了，比如自身系统的功能：日志记录，默认值，类型转化，script脚本(EL表达式)。都是通过扩展接口实现，也比较方便切换成不同的实现.。

 

有兴趣的同学，可以看下googlecode上的代码，有问题欢迎联系！

 

googlecode地址 :  http://code.google.com/p/mapping4java

 

相关功能测试代码：

BeanCopyTest.java	3.1 KB
BeanMapTest.java	2.1 KB
BeanMappingTest.java	7.8 KB
ConfigTest.java	1.7 KB
ConvertorTest.java	8.5 KB
ScriptExecutorTest.java	2.2 KB
ScriptTest.java	2.7 KB

 

性能测试代码： 

CopyPerformance.java	12.9 KB
MapPerformance.java	3.0 KB

 

需求搜集

结合了dozer的一些特性，也顺便整理了一下自己的后续action的一些功能点，做了适当取舍。 

 

issue列表: http://code.google.com/p/mapping4java/issues/list

评论

28 楼 agapple 2011-06-13  

hobitton 写道

agapple 写道

yimlin 写道

貌似还不支持父类（抽象定义）+子类继承，遇到相同情况不给搞死，另外父子类存在相同属性怎么处理，貌似会出bug吧。。。。

针对eclipse的重构工具支持给跟上，不然想死的心都有了！

看来是内行人哈，需求记下了。无意中翻到有个类似的工具： dzoner。
功能是蛮相似的，但从一些别人介绍中是基于beanutils做的一些扩展，性能上估计存在一些问题。不过它支持的一些功能到是可以参考和实现一下。只是时间的问题

呵呵，您说的工具应该是dozer吧？

恩，笔误. 多谢指出，已经修正。
结合了dozer的一些特性，也顺便整理了一下自己的后续action的一些功能点，做了适当取舍。
issue: http://code.google.com/p/mapping4java/issues/list

27 楼 hobitton 2011-06-13  

agapple 写道

yimlin 写道

貌似还不支持父类（抽象定义）+子类继承，遇到相同情况不给搞死，另外父子类存在相同属性怎么处理，貌似会出bug吧。。。。

针对eclipse的重构工具支持给跟上，不然想死的心都有了！

看来是内行人哈，需求记下了。无意中翻到有个类似的工具： dzoner。
功能是蛮相似的，但从一些别人介绍中是基于beanutils做的一些扩展，性能上估计存在一些问题。不过它支持的一些功能到是可以参考和实现一下。只是时间的问题

呵呵，您说的工具应该是dozer吧？

26 楼 agapple 2011-06-13  

yimlin 写道

貌似还不支持父类（抽象定义）+子类继承，遇到相同情况不给搞死，另外父子类存在相同属性怎么处理，貌似会出bug吧。。。。

针对eclipse的重构工具支持给跟上，不然想死的心都有了！

看来是内行人哈，需求记下了。无意中翻到有个类似的工具： dozer。
功能是蛮相似的，但从一些别人介绍中是基于beanutils做的一些扩展，性能上估计存在一些问题。不过它支持的一些功能到是可以参考和实现一下。只是时间的问题

25 楼 star022 2011-06-13  

googlecode 无法访问的 可以在host增加下面内容：
74.125.71.104 code.google.com
74.125.71.104 encrypted.google.com
74.125.71.104 suggestqueries.google.com
74.125.71.104 mail.google.com
74.125.71.104 groups.google.com
74.125.71.104 groups.google.com.hk
74.125.71.104 docs.google.com
74.125.71.104 docs0.google.com
74.125.71.104 docs1.google.com
74.125.71.104 spreadsheets.google.com
74.125.71.104 spreadsheets0.google.com
74.125.71.104 webcache.googleusercontent.com
74.125.71.104 sites.google.com
74.125.71.104 talkgadget.google.com
74.125.71.104 clients1.google.com
74.125.71.104 clients2.google.com
74.125.71.104 clients3.google.com
74.125.71.104 clients4.google.com

24 楼 star022 2011-06-13  

抛出异常的爱 写道

重构属性名子时想死。。。。。

确实 这种情形应该大力发扬"约定大约配置"的价值。。。。

23 楼 yimlin 2011-06-13  

如果再有一个可视化编辑器就更好了，可支持数据同步映射了（这一直是数据处理的一个大头，加上重复识别就更完美了）。

22 楼 yimlin 2011-06-13  

貌似还不支持父类（抽象定义）+子类继承，遇到相同情况不给搞死，另外父子类存在相同属性怎么处理，貌似会出bug吧。。。。

针对eclipse的重构工具支持给跟上，不然想死的心都有了！

21 楼 agapple 2011-06-13  

lqixv 写道

稳定了吗？准备用在我们项目上替换掉 beanutils，那玩意太慢了，我的机器上，一个 bean 的属性复制，动不动就 一两百 毫秒，有时甚至有几百毫秒的。

不管是cglib的BeanCopier，还有本文中的BeanMapping，在第一次copy时都会涉及到bean属性的分析过程，所以第一次慢也是难免的。看一个工具的性能，得有warmup的过程
所以性能上的提升，更多的是在自身工具的执行代码优化上，包括反射调用优化。
结构和框架设计上基本已经定型，不会有改变，代码是基本稳定了。目前单元测试在70%左右，争取这周可以提升到90%以上，到时候可以出一个稳定的版本。

如果有兴趣使用的话，可以一起加入开发和测试 

20 楼 agapple 2011-06-13  

peak 写道

一层的复制比较简单，最好是多层，还要带集合。。。
现在的对象多数都这种的。。

是支持多层转化的，只不过默认copy时，针对复合对象只是做引用复制(大部分还是处于这样的需求)。如果需要做多层复制，是可以通过mapping="true"参数控制

支持list,map转换，这也只是convetor转化器的扩展而已。如果是有特殊的对象转化处理，比如枚举值。也可以自定义convetor

19 楼 agapple 2011-06-13  

JE帐号 写道

agapple 写道

neverforget 写道

google code 地址错了

hi,地址没错，可能你得翻个墙了

把地址从https改为http即可.
admin权限操作的时候才需要https.
一般的查看用http即可.

多谢提醒，这个也没多留意这个差别。 url都已经做了下修改

18 楼 lqixv 2011-06-13  

稳定了吗？准备用在我们项目上替换掉 beanutils，那玩意太慢了，我的机器上，一个 bean 的属性复制，动不动就 一两百 毫秒，有时甚至有几百毫秒的。

17 楼 peak 2011-06-13  

一层的复制比较简单，最好是多层，还要带集合。。。
现在的对象多数都这种的。。

16 楼 JE帐号 2011-06-13  

agapple 写道

neverforget 写道

google code 地址错了

hi,地址没错，可能你得翻个墙了

把地址从https改为http即可.
admin权限操作的时候才需要https.
一般的查看用http即可.

15 楼 stone2083 2011-06-13  

agapple 写道

抛出异常的爱 写道

重构属性名子时想死。。。。。

呵呵，有同感，特别是针对老系统做迁移或者重构。
还有就是跨部门系统合作时，对方老喜欢搞弱类型的map,string传递，接口文档机制也没有很好的建立。对于我们应用开发是个痛苦的事，所以我喜欢包上一层map<->Bean的的转化，实现代码即文档。

只能是一种权衡。
使用强依赖，重构时候不易出错，但是编码复杂，并且是重复劳动力
利用弱依赖，方便编码，但是重构是个噩梦。
好在模型相对稳定，字段变化的频率不大。只要不滥用，还是在可控范围内。

14 楼 agapple 2011-06-13  

抛出异常的爱 写道

重构属性名子时想死。。。。。

呵呵，有同感，特别是针对老系统做迁移或者重构。
还有就是跨部门系统合作时，对方老喜欢搞弱类型的map,string传递，接口文档机制也没有很好的建立。对于我们应用开发是个痛苦的事，所以我喜欢包上一层map<->Bean的的转化，实现代码即文档。

13 楼 抛出异常的爱 2011-06-13  

重构属性名子时想死。。。。。

12 楼 agapple 2011-06-13  

Mr.Chris 写道

之前也想写个类似的东东用来在PO、DO等之间自动转化，貌似你这个可以直接用上了。赞！精华一枚。

哈哈，多谢支持。看来想重新写这个的初衷都是一样

还有就是看到你的五道杆头像，立马让我想到公司里的一班子人拍的照片

11 楼 Mr.Chris 2011-06-13  

之前也想写个类似的东东用来在PO、DO等之间自动转化，貌似你这个可以直接用上了。赞！精华一枚。

10 楼 agapple 2011-06-13  

pengranxiang 写道

请问性能测试的部分，是用什么工具做的？

就自己写的普通的java代码，就是注意下程序的预热(类加载，jit编译优化)，设置下基本的jvm内存参数。 选择一台服务器上去跑(我选的是Linux 2.6.18内核，x64 ,5G内存，8颗cpu。是台虚拟机，主机是4核4颗cpu，24G内存，虚拟了这样的机器4个)

9 楼 pengranxiang 2011-06-13  

请问性能测试的部分，是用什么工具做的？