摘要

當前web後端開發，都是使用多層工程結構，需要在VO,BO,DTO,DO等各種數據結構中相互轉換。這些轉換代碼都是些比較簡單的字段映射，類型轉換，重複性工作比較高，可以使用一些工具解放我們的雙手

技術方案

實現類轉換的方案很多，不同方案有優缺點，需要開發者自行取捨

方案	優點	缺點
手寫代碼	1. 靈活性高 2.方便後續重構	1. 重複性工作多 2. 手寫代碼容易遺漏掉有些字段
BeanUtils.copyProperties 使用反射實現	1. 使用簡單 2. Apache 的包效率比較低，spring的包效率可以接受	1. 複雜場景支持不足，控制copy粒度太粗 2. 不易重構
mapstruct	1. 靈活性高支持簡單，複雜，嵌套，自定義擴展等多種手段 2. 編譯期生成，沒有效率問題	不方便後續重構

方便後續重構方便後續重構的意思是當你需要更改DTO字段時，可以利用編譯器的引用關係直接refactor掉

綜上考慮mapstruct方案優於beanutils.copy,和手寫方案對比，有一定劣勢，需要取捨。個人意見，對於改字段重構，這種應該通過測試用例去保證，而不是依賴編輯器的功能。此外使用mapstruct進行轉換後，類引用關係還在，重構可以通過識別類的粒度，來保證不出錯。如果再考慮到手工黨的出錯概率，和開發效率mapstruct顯然更優。

實現

1. 引入依賴包

1. 爲maven compile plugin 設置annotation processor

1. IDEA 安裝一個mapstruct 插件 有了這個插件後，可以找到映射類的屬性，一些拼寫校驗

常用用法

默認情況下，當屬性值與目標實體的名稱相同時，就會隱式映射

其他通用轉換

屬性值不相同時

Collection對象轉換

JAVA 構造器

通過expression 來調用Java代表

qualifiedByName

如果構造器滿足不了，還可以自定義方法，然後再調用

接口默認實現

mapstruct是用戶定義接口，然後自動生成實現類，如果轉換類中有非常定製的轉換，不想通過mapstruct來轉換，我們可以直接使用接口默認實現

當然還有其他功能可以使用，比如Decorator,這裏不再一一列舉，更多豐富的功能可以查看mapstruct 細節使用

參考

https://blog.csdn.net/w605283073/article/details/107371462

mapstruct 細節使用