MapStruct処理Javaにおけるエンティティとモデルの間の不整合属性変換の方法


要約:前にMapStrutの簡単な使い方を紹介しましたが、MapStrutの最も重要な特徴はJavaのエンティティとモデルとの間の不整合属性の変換を処理することです。
実体モデル
Userオブジェクトがあります。

public class User {
  private Integer id;
  private String name;
  private double account;
  private boolean married;
// setters, getters, toString()
}
Employeeオブジェクトがあります。

public class Employee {
  private int id;
  private String ename;
  private String position;
  private String married;
// setters, getters, toString()
}
ビジネスシーン
  • はUserとEmployeeオブジェクト間の変換を必要とする。
  • Userのname属性は、Employeeのename属性に対応しており、値は同じで、タイプは同じで、名前は
  • と異なる。
  • Userのmaried属性(trueとfalseの値を取る)は、Employeeのmaried属性(YとNの値を取る)に対応しており、その値は異なり、タイプは異なり、名前は同じである。
  • 分析と実現
    最も愚かな方法は自分で作成したセット方法とgetter方法で、大量にget/setコードを積み上げて、コードの長さと読み取りの難しさを増やしました。ツールを利用するBenUtilsは第一の需要を処理することができますが、第三の需要はどうすることもできません。このときMapStrutは役に立ちます。一番簡単な配置は次のようにできます。
    
    @Mapper
    public interface UserMapper {
      UserMapper INSTANCE = Mappers.getMapper(UserMapper.class);
      Employee userToEmployee(User user);
      User employeeToUser(Employee employee);
    }
    第二の需要の場合、以下のように実施することができ、注釈@Mappingは、どのフィールドsourceをどのフィールドtargetに変換するべきかを指定することができる。
    
    @Mapper
    public interface UserMapper {
      UserMapper INSTANCE = Mappers.getMapper(UserMapper.class);
      @Mappings({
        @Mapping(source="name", target="ename")
      })
      Employee userToEmployee(User user);
      @Mappings({
        @Mapping(source="ename", target="name")
      })
      User employeeToUser(Employee employee);
    }
    第三の需要は少し変態ですが、実際に発生したのは私達のプロジェクトの中で、実現するのは確かに煩雑です。
    まず、カスタム変換ロジック、ブール値から文字列、ブールのtrueは文字列のY、ブールのfalseは文字列のNに対応します。
    
    public class UserTransform {
      public String booleanToString(boolean value){
        if(value){
          return "Y";
        }
        return "N";
      }
      public boolean strToBoolean(String str){
        if ("Y".equals(str)) {
          return true;
        }
        return false;
      }
    }
    使いやすいです。インタフェースの注釈Mapperにusesパラメータを追加します。値は先ほどの変換ロジッククラスが必要です。
    
    @Mapper(uses = UserTransform.class)
    public interface UserMapper {...}
    結果と分析
    Junnit Testで二つのテスト方法を書いて、それぞれUserオブジェクト変換Employeeをテストします。Employeeオブジェクト変換User。
    
    public class MidTest {
      @Test
      public void midTest(){
        User user = new User();
        user.setId(125);
        user.setName("Lee");
        user.setMarried(true);
        Employee e = UserMapper.INSTANCE.userToEmployee(user);
        System.out.println(e);
      }
      @Test
      public void midTest2(){
        Employee e = new Employee();
        e.setId(222);
        e.setEname("Chao");
        e.setMarried("N");
        User u = UserMapper.INSTANCE.employeeToUser(e);
        System.out.println(u);
      }
    }
    結果は以下の通りです
    User[id=222,name=Cho,account=0.0,maried=false]
    Employee[id=125,ename=Lee,position=null,maried=Y]
    変換結果が予想通り、変換期間に存在しない属性は、デフォルト値(accountとposition)があり、包装類も識別できます。自動生成されたUserMapperImpl.javaからは、employee.setMarried( userTransform.booleanToString( user.isMarried() ) );は、先のカスタム変換ロジックを使用しています。第三の需要は少ないですが、出会っても解決しにくいです。MapStructのカスタム関数は確かに便利です。しかし、他の変換ツールと比べて、手の難易度が高く、配置もやや複雑です。
    プロジェクトコードはコードクラウドに委託されています。
    締め括りをつける
    以上はこの文章の全部の内容です。本文の内容は皆さんの学習や仕事に対して一定の参考学習価値を持ってほしいです。ありがとうございます。もっと知りたいなら、下のリンクを見てください。