背景
一切還要從我的上一家公司講起，我的上一家公司是一家獨角獸企業，說大不大說小不小的那種，公司氛圍也是比較注重技術，我當時入職之後的第一課就是閱讀我們 CTO 寫的開發規範，其中他把 Java 專案的目錄結構劃分的非常清楚，大概是下面這個樣子的：
我當時覺得這種分層結構劃分的非常優雅與合理，當然以上只是一個大概，更細節的分層我沒有表露，但是隨之而來在實際中使用的過程中，這樣一個三層結構也帶來了一個問題，那就是物件傳輸非常麻煩，因為每層都會有一個特有的物件。
下面我舉一個例子，假如我們要插入一個 User 物件，那麼它可能要經過以下二次物件轉換：
以上只是一個比較簡單的例子，相信大家已經可以從中看出開發者們需要寫一些很繁瑣但是很沒意思的程式碼（手動 get/set），比如上圖中的三個物件可能欄位都是一模一樣的，但卻需要重複寫兩次 Convert 去進行物件的轉換。
當然這樣設計當然也有好處，那就是解耦，比如我們現在用的資料庫是 Mysql，如果要換成 Mongo 只需要把第二次物件轉換的程式碼稍微修改一下即可，這也是這樣設計的初衷。
常見方案
這麼一個繁瑣的事難道就沒有一些方案進行解決嗎？當然有，一般來說有兩種方式：
- BeanUtil / JSONObject
- MapStruct
先來說第一種方式吧，無論 BeanUtil 是深拷貝還是淺拷貝，它對我們開發者來說細節都是不可見的，一旦某個欄位賦值出現了問題，我們並沒有辦法去進行程式碼的排查，因為我們沒辦法檢視物件轉換的細節，JSONObject 也有相同的問題。
然後就是第二種方式，MapStruct 在前段時間是一個非常火的方案，它和 Lombok 非常類似，在程式碼編譯期幫助我們去生成物件之間的轉換程式碼，我們也可以通過 IDEA 的提示去檢視編譯後的程式碼，我司除了手動 get/set 程式碼，最多的就是使用 MapStruct 進行處理。
但是對我而言，MapStruct 還是有一些缺點，首先我的 IDEA 經常沒有檢視編譯後程式碼的提示，其次就是如果轉換物件的某個欄位不一樣的時候，需要學習 MapStruct 的一些用法進行處理，有一定的學習負擔，反正我到現在都沒學會?。
我的方案
最終我為了方便，決定自己開發一個 IDEA 外掛並起名為 BeanMappingKey，目前已經迭代到 1.X 版本，主要思想是通過外掛的方式為我們需要轉換的物件自動生成轉換程式碼。
目前暫時有三種用法：
- 根據物件生成對應的 get/set 方法，支援建造者模式。
- 根據 Class 生成對應的 get/set 方法，支援建造者模式。
- 根據一個方法的入參和返回值，進行物件的轉換程式碼生成，支援建造者模式。
其中，第一種和第二種生成起來是差不多的，具體可見以下例子：
上圖的示例，是我們選中一個 Class 類進行程式碼的生成，根據這個類是否是建造者模式，來生成對應風格的程式碼，生成之後的程式碼被拷貝到剪貼簿上，可以自由貼上。
第二種方式，對於我來說是更加常用的，因為轉換程式碼往往是寫在一個方法裡面的，通過選中方法名匹配入參和返回值進行程式碼生成，類似下面的例子：
匹配的邏輯就是根據欄位名進行匹配，匹配失敗的話則會留空，同時不只支援一個入參，可以對多個入參進行匹配，就像下面這樣：
以上就是我對這個外掛的介紹了，各位讀者如果有興趣的話可以在IDEA上面下載上試試：
在
Windows系統上安裝:File>Settings>Plugins>Browse repositories...>Search for "BeanMappingKey">Install Plugin
在
MacOS系統上安裝:Preferences>Settings>Plugins>Browse repositories...>Search for "BeanMappingKey">Install Plugin
手動安裝:- 下載 latest release 之後， 選擇
Preferences>Plugins>Install plugin from disk...
- 下載 latest release 之後， 選擇
注：暫且只支援 2020 以上版本的 IDEA，安裝之後無需重啟。
目前我的這個外掛依然還在完善中，對於複雜型別支援的還不夠完善，比如物件裡面巢狀物件的情況，我打算下一階段繼續對這塊痛點進行升級完善，下面是此外掛的地址：
- Github：https://github.com/rookie-ricardo/BeanMappingKey
- Plugin：https://plugins.jetbrains.com/plugin/18264-beanmappingkey
2022-06-06更新：外掛更新 2.0 版本，已經支援物件巢狀的生成，歡迎大家在IDEA中下載使用。