Java日常开发工作中,需要在各种DO、DTO、BO、AO、VO之间转换,有时候总是感叹为什么要定义这么多XO,就简单定义一下不行吗?而实际情况是,考虑到开发中领域模型的扩展性设计,还真得定义不同的XO去辨识区分不同实体边界,这样代码才方便扩展维护,否则全都堆在一个实体类里面,不仅恶心了开发,还会带来很多代码稳定性问题。
那么问题来了,多层应用程序通常需要在不同的对象模型(例如DTO和实体)之间进行映射,编写映射代码是一项繁琐且容易出错的工作,到底应该采取什么样的转换方式是比较好的方式呢?今天就来聊聊这个话题。
我们先来了解一下各个XO是如何分类的,毕竟它们才是我们想要转换的对象。相信 POJO 大家都比较熟悉,通常专指只有setter/getter/toString的简单类,而在它之下,还有一些细分,包括DO/DTO/VO等。比较常见的是下面几种:
当然,除了这些简单类以外,还有一些包含业务逻辑的实体类,比如 BO(Business Object):业务对象,由Service层输出的封装业务逻辑的对象。
比较常见的对象转换方式主要有两种,我们可以在很多老代码当中看到它们的身影。
getter/setter手工硬编码的方式相信很多 Java 开发同学都异常熟练,它的痛点也非常明显,就是当一个类有几十个属性的时候,代码编写效率非常低下,而且丑陋,最重要的是,当新扩展一个字段以后,往往容易忽略在 mapping convert 文件中添加相应的属性映射,给业务带来一定的潜在风险(error-prone)。当然硬编码也不是一无是处的,它的执行效率非常高,这个后文会分析。
而使用BeanUtil.copyProperties的方式进行转换的话就要好一些了,我们可以在业务逻辑当中一行代码就解决掉对象转换的问题,不会使得代码非常冗长,但它的坑也不少,由于使用反射的方式去进行转换,如果涉及到频繁对象转换操作就会有性能问题(后文会有分析),同时对开发者定位问题也不友好,出问题后我们很难定位到字段是在哪里进行的赋值操作。
Object Mapping 技术从大的角度来说分为两类,一类是运行期转换,另一类则是编译期转换,它们的区别主要是:
说完它们的区别,那么它们的Object Mapping表现差异究竟如何?我们可以写代码验证,这里方便起见就直接引用 GitHub 上面java-object-mapper-benchmark的项目结果说明,要转换的对象是 Order 实体与 OrderDTO,它们的关联关系如下图所示。
机器配置如下:
运行结果如下:
感兴趣的同学可以去把代码下载下来亲自验证一下。从图中可以很明显感受到的是,反射 Object Mapping 确实比 get/set 的方式慢很多。另外,综合比较性能、问题排查、文档、成熟度、扩展性等因素,MapStruct 是一个不错的 Object Mapping 选择。
...<properties> <org.mapstruct.version>1.3.1.Final</org.mapstruct.version></properties>...<dependencies> <dependency> <groupId>org.mapstruct</groupId> <artifactId>mapstruct</artifactId><!-- use mapstruct-jdk8 for Java 8 or higher --> <version>${org.mapstruct.version}</version> </dependency></dependencies>...<build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.5.1</version> <configuration> <source>1.6</source><!-- or higher, depending on your project --> <target>1.6</target><!-- or higher, depending on your project --> <annotationProcessorPaths> <path> <groupId>org.mapstruct</groupId> <artifactId>mapstruct-processor</artifactId> <version>${org.mapstruct.version}</version> </path> </annotationProcessorPaths> </configuration> </plugin> </plugins></build>
2 . 定义实体对象。
下面两个类非常相似,有一个号码属性名不一样,同时在 PeopleDTO 中有个 User 对象,而在 PeopleEntity 中则是两个单独属性。
PeopleEntity.java:
publicclass PeopleEntity { private Integer age; private String name; private String callNumber; private String address; private String emile; //constructor, getters, setters etc.}
PeopleDTO.java:-
publicclass PeopleDTO { private String phoneNumber; private String address; private String emile; private User user; //constructor, getters, setters etc.}
User.java:-
publicclass User { private Integer age; private String name; //constructor, getters, setters etc.}
3 . 定义Mapper接口 要生成一个PeopleDTO与PeopleEntity对象相互转换的映射器,我们需要定义一个mapper接口。当实体类有些属性不一样时,我们可以通过@Mapping注解来进行转换。
PeopleMapper.java:
@Mapperpublicinterface PeopleMapper { PeopleMapper INSTANCE = Mappers.getMapper(PeopleMapper.class); /** * PO转DTO * * @param entity PO * @return DTO */ @Mapping(target = "phoneNumber", source = "callNumber") @Mapping(target = "user.name", source = "name") @Mapping(target = "user.age", source = "age") PeopleDTO entityToDTO(PeopleEntity entity); /** * DTO转PO * * @param peopleDTO DTO * @param entity PO */ @Mapping(target = "callNumber", source = "phoneNumber") @Mapping(target = "name", source = "user.name") @Mapping(target = "age", source = "user.age") void updateEntityFromDto(PeopleDTO peopleDTO, @MappingTarget PeopleEntity entity);}
4 . 使用Mapper。
使用Mapper有两种方式,第一种我们不需要做过多的配置,直接使用Mappers通过工厂完成Mapper实现类的获取。
//Mapper接口内部定义publicstatic GoodInfoMapper MAPPER = Mappers.getMapper(GoodInfoMapper.class);//外部调用GoodInfoMapper.MAPPER.from(goodBean,goodTypeBean);
第二种方式是使用Spring的配置方式,我们需要在@Mapper注解内添加componentModel属性值,配置后在外部可以采用@Autowired方式注入Mapper实现类完成映射方法调用。-
//注解配置@Mapper(componentModel = "spring")//注入Mapper实现类@Autowiredprivate GoodInfoMapper goodInfoMapper;//调用goodInfoMapper.from(goodBean,goodTypeBean);
总结
MapStruct的使用方法还有很多,能够胜任业务开发工作中几乎所有的对象转换工作,上面只是简单演示了它的基本用法,更多用法大家可以继续探索。总体看来,MapStruct 的优点主要集中在三个方面:
大家有什么使用上的心得或疑惑的话,欢迎留言探讨。
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8