Orika是一个java实体映射框架，可以将两个不同的类对象进行相互转换。如果你是一名有经验的开发工程师，应该耳熟能详dto,vo,bo,entity等等这类的，我们免不了对象之前的相互转换，可也许会手动一个一个去转换，也有人可以会用BeanUtil去互换，当然都是可以的，但手动一个一个写会让代码非常的糟糕，BeanUtil使用了大量反射，性能略有影响。
如果你还不知道Orika具体使用方法，建议你先上网学习下这个框架如何去使用，这篇文章不做介绍，我们主要做源码分析。
默认情况下，我们在转换对象时，会使用UseCustomMapperStrategy进行解析。进入源码正题：
image.png
这个方法就是映射的最重要的主体。
它有三个参数：
第一个参数是原始对象。
第二个参数是目标对象，初始为空。
第三个参数是上下文。
目标对象创建方法：
我们点击进入getInstance方法。经过一定追踪后，最后使用的非空构造方法反射创建，这没有什么亮点可言。
image.png
目标对象设置值方法：
我们把重点转移到了mapAtoB方法，没有错，它就是重点。
image.png
但是很可惜，我们在debug的时候却debug不了了，我们观察customMapper的类型，竟然发现是一个动态生成的类对象。
image.png
那么这个对象从何而来，我们又开始新一轮的探索。
经过本人一番debug,最后总算定位到了这个Class的来源，原来他是从MapperGenerator这个类中生成的，这个类是一个重点，他负责生成class文件，我们定位到build方法。
image.png
从这个方法我们可以得知，所有的mapper都是GeneratedMapperBase的子类，打开GeneratedMapperBase源码看一眼：
image.png
一个抽象类，它里面有两个重要的方法：
image.png
回过头，我们继续看他的class文件是怎么生成的，这里我们重点来看下方法的代码生成，进入这个类的一个私有方法addMapMethod，
image.png
我们看到在这个方法中，采用硬编码形式先在内存生成.java文件内容，然后动态编译成一个Class文件，再载入内存，orika这里采用的是javassist实现的这一功能。我们来看看他生成的代码，在这个方法最后一行代码下段跟踪：
image.png
out就是生成的代码：
public void mapAtoB(java.lang.Object a, java.lang.Object b, ma.glasnost.orika.MappingContext mappingContext) {
super.mapAtoB(a, b, mappingContext);
com.luhui.orika.Cls1 source = ((com.luhui.orika.Cls1)a);
com.luhui.orika.Cls2 destination = ((com.luhui.orika.Cls2)b);
if ( (!(((java.lang.String)source.getStr1()) == null))) {
destination.setStr1("" + ((java.lang.String)source.getStr1()));
} else {
destination.setStr1(null);
}
if ( (!(((java.lang.Integer)source.getStr2()) == null))) {
destination.setStr2("" + ((ma.glasnost.orika.Converter)usedConverters[0]).convert(((java.lang.Integer)source.getStr2()), ((ma.glasnost.orika.metadata.Type)usedTypes[0])));
} else {
destination.setStr2(null);
}
if(customMapper != null) {
customMapper.mapAtoB(source, destination, mappingContext);
}
}
前面我们提到这个生成的类是继承自GeneratedMapperBase的，这里的super.xxx我们也就能清楚他是做什么的了。
这也就是前面说的mapAToB方法具体实现。
可以看到，orika使用字节码技术动态生成代码，没有使用反射操作，这也就是性能大大提升的原因，而且内部还使用了大量的缓存机制，据说是BeanUtil性能的120倍。
网友评论