您好,登錄后才能下訂單哦!
這篇文章主要講解了“如何使用Mapstruct”,文中的講解內容簡單清晰,易于學習與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學習“如何使用Mapstruct”吧!
在Java中,有三種方式來處理這些屬性拷貝:
直接硬編碼,把代碼硬懟上去
使用各種BeanUtils,通過反射完成賦值
使用類似MapStruct的工具,直接在編譯期完成
1. 如何使用?
照例,需要在pom中加入依賴包,我們這里用的是1.4.1.Final版本。
<dependency> <groupId>org.mapstruct</groupId> <artifactId>mapstruct</artifactId> <version>${org.mapstruct.version}</version> </dependency>
這還沒完,還需要在pom中的build部分,增加一個插件。搞這么復雜,是因為它的原理和lombok是一樣的,同樣通過APT在編譯器實現的。
這意味著,它的代碼,在編譯期就完成了。不需要反射,所以效率就和直接寫get、set,是一樣的。
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.8.1</version> <configuration> <source>1.8</source> <target>1.8</target> <annotationProcessorPaths> <path> <groupId>org.mapstruct</groupId> <artifactId>mapstruct-processor</artifactId> <version>${org.mapstruct.version}</version> </path> <path> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>1.18.16</version> </path> <path> <groupId>org.projectlombok</groupId> <artifactId>lombok-mapstruct-binding</artifactId> <version>0.2.0</version> </path> </annotationProcessorPaths> </configuration> </plugin>
這時候,我們就可以使用它提供的注解,方便的進行屬性拷貝了。
@Mapper(nullValueCheckStrategy = NullValueCheckStrategy.ALWAYS) public interface Transform { Transform T = Mappers.getMapper(Transform.class); Member fromMemberEntity(MemberEntity entity); MemberEntity fromMember(Member member); }
上面是一段示例代碼。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注解完成這個轉化。
@Mappings({ @Mapping(source = "measureType.value", target = "measureType") }) ProductUnitEntity fromUnit(Unit v);
編譯后的代碼如下所示。有了source和target,就可以實現比BeanUtils更加牛x的行為。你甚至可以通過dateFormat做一些日期轉化之類的。
其實,上面的measureType是一個枚舉類型。如何將普通的類型轉化為枚舉類型呢?我們只需要提供一個default方法就ok了。mapstruct會判斷參數類型和返回值,所以說方法的名稱可以是任何合法的值。
default Unit.MeasureType measureTypeIntegerToDomain(Integer value) { for (Unit.MeasureType s : Unit.MeasureType.values()) { if (s.getValue() == value) { return s; } } return null; }
那mapstruct能實現List之間的轉化么?也是可以的。下面兩行代碼,就能夠自動的補充for循環,讓你的代碼更加簡潔。
List<StockKeepingUnit> fromSkuEntityList(List<StockKeepingUnitEntity> v); List<StockKeepingUnitEntity> fromSkuList(List<StockKeepingUnit> v);
End那么問題來了。
既然這么好的東西,那為什么現在的很多項目,都不用mapstruct,甚至連BeanUtils都不用,直接手工在那里get、set呢?
一種原因是,這些工具會大幅減少代碼量。mapstruct+hibernate-validate,一個管轉化,另一個管驗證,簡直就是以代碼行數論天下的公司的噩夢。績效會降低的!
另一種原因就是,使用這些工具,并 不利于項目的重構 。假如你在DTO里把a字段改成了b字段,mapstruct都貼心的為你忽略了這些變化。你的項目代碼并不會提示錯誤,風險將直接帶到運行時。
而使用get、set的方式,除了代碼量變的非常多以外,唯一的風險就是開發人員忘記了為某個新增的字段賦值。
在這種情況下,機器干的活,并不一定比人類可靠。所以使用mapstruct有一個大的前提:你的團隊,能夠通過約定,不給變量亂起名字,不亂重構。如此,才能發揮它的價值。
感謝各位的閱讀,以上就是“如何使用Mapstruct”的內容了,經過本文的學習后,相信大家對如何使用Mapstruct這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關知識點的文章,歡迎關注!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。