喜新厌旧，是我的本性。

一股想吐的感觉。这种思想的转变，从侧面上证明了，我并不是一个专一的人。

因为我是一条狗。

喜新厌旧，是我的本性，即使我把自己表现的很纯洁。

按理说，牛x的人物并不需要关注语言层面这种较低级的问题。但是，无论是什么语言，各种属性拷贝，是在工程上绕不开的问题。比如折腾人的VO、BO、DTO、DO等。

项目中的代码，有六成，是在做这些无用的转换和各种数据验证。这个比例是我瞎诌的，但也相差无几。

在Java中，有三种方式来处理这些属性拷贝：

1. 直接硬编码，把代码硬怼上去
2. 使用各种BeanUtils，通过反射完成赋值
3. 使用类似MapStruct的工具，直接在编译期完成

其实嘛，哪一种都有利弊，有些东西虽然香，但实际用起来，还是要思量一下。个个打扮的花枝招展的，都是外在的皮囊。

本文主要介绍Mapstruct的使用，并从这香喷喷的工具中，闻一下其中变馊的味道。

1. 如何使用?

照例，需要在pom中加入依赖包，我们这里用的是1.4.1.Final版本。面是一段示例代码。Mapper注解，标志着这是一个类型转换工具(对象映射器)，它提供了很多策略供我们选择。直接写接口文件，并不需要做一些额外的动作，mapstruct就知道你要干什么!

在传统的编程中，如果Member的属性非常的多，我们需要手工完成这个过程，代码会非常的多。

使用Mapperstruct之后，这部分重复的劳动，工具都替我们做了。图表明了，代码在target下的generated-source目录下生成，这就是我们上面添加的插件的功劳;代码的内容，其实就是一些非空判断和get、set等。相同字段名相同类型的属性，将会无差别的拷贝过去。

如果你的bean属性非常的多，这个工具会让你的代码由几百行，变成几行!

2. 与其他方式比较

那mapstruct有什么优势么?为什么不直接使用BeanUtils?它们的效果一样的啊，而且后者各种类库都有提供。

主要原因，就是效率问题。

BeanUtils是通过反射实现的，效率肯定很低;而mapstuct是基于APT实现的，没有性能损耗。

BeanUtils的属性拷贝，在判断空值和不同类型的属性时，有很多障碍，会歇菜;而mapstruct有非常灵活的策略和转化方式，自定义性比较强(后面会谈到)。

3. 复杂场景

那下面我们就来看一个复杂的场景。

如果你的bean中，只有一些普通的属性，那么使用mapstruct，就是如丝般的顺滑。但总有一些异常情况，需要使用更高级的处理方式。

假设我想要由Unit转化为ProductUnitEntity，但其中有个字段measureType它们的类型不一样，我们就可以使用Mappings注解完成这个转化。

（编辑：东莞站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!