はじめに: Ali 開発マニュアルには、必須の開発仕様があります。POJO クラスのブール変数には先頭に is を付けないでください。
Alibaba の開発マニュアルでも、MySQL 仕様のテーブル作成規約の第一項で、yes または no を表す変数は is_xxx という命名方法を採用しています。
Mybatis または mybatis-plus が本番プロジェクトに統合されている場合、pojo エンティティ オブジェクトのプロパティがテーブル フィールドと異なる場合、
どのようにマッピングできるのでしょうか? では、なぜブール変数の前に is を付けることができないのでしょうか? その理由について以下でお話しましょう。
pojoクラスを定義する
package com.example.demo.entity;
import com.baomidou.mybatisplus.annotation.IdType;
import com.baomidou.mybatisplus.annotation.TableId;
import com.baomidou.mybatisplus.annotation.TableName;
import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
import lombok.NoArgsConstructor;
import java.io.Serializable;
@Data
@AllArgsConstructor
@NoArgsConstructor
@TableName("user")
@Builder
public class User implements Serializable {
private static final long serialVersionUID = 1L;
@TableId(value = "id", type = IdType.AUTO)
private Integer id;
private String name;
private Integer age;
private String addr;
private Integer isModify; //是否被修改
private Boolean isDelete; //是否被删除
}
User オブジェクトには 2 つの変数属性があり、1 つは isModify で、もう 1 つは isDelete です。どちらの変数も is で始まりますが、対応するデータ型は異なります。isModify に対応するデータ型は Integer で、対応するデータ型は isDelete です。型はブール型です。
@Data: 誰もが実稼働プロジェクトでこのアノテーションを使用すると思います。これは lombok フレームワークのアノテーションであり、プロジェクト内のゲッター コードとセッター コードを大幅に節約できます。以下は @Data の定義です。Getter、Setter、RequiredArgsConstructor、ToString、EqualsAndHashCode で構成されていることがわかります。
package lombok;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
/**
*
* @see Getter
* @see Setter
* @see RequiredArgsConstructor
* @see ToString
* @see EqualsAndHashCode
* @see lombok.Value
*/
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.SOURCE)
public @interface Data {
String staticConstructor() default "";
}
@Data で注釈が付けられた、生成された User オブジェクトの isModify および isDelete の Getter メソッドと Setter メソッドを以下に示します。ブール変数 isDelete に対応する Getter メソッドと Setter メソッドは、is プレフィックスを省略するため、結果を取得できないことがわかります。属性の削除です。基本データ型 Boolean isDelete の属性として定義されており、そのメソッドも isDelete() であるため、フレームワークが逆解析するときに、対応する属性名が削除であると「誤って認識」され、その結果、属性を削除できなくなります。得られた。
public Integer getIsModify() {
return isModify;
}
public void setIsModify(Integer isModify) {
this.isModify = isModify;
}
public Boolean getDelete() {
return isDelete;
}
public void setDelete(Boolean delete) {
isDelete = delete;
}
この問題は、@Data アノテーションを使用せず、開発ツール IDEA を使用して Getter メソッドと Setter メソッドを自動的に生成する場合にも発生します。この問題を解決するには、Getter メソッドと Setter メソッドを手動で記述する必要があります。明らかに、このメソッドは非常に重く、望ましくありません。コードの読みやすさが向上するだけでなく、開発の作業負荷とコストも増加します。
public Integer getIsModify() {
return isModify;
}
public void setIsModify(Integer isModify) {
this.isModify = isModify;
}
public Boolean getIsDelete() {
return isDelete;
}
public void setIsDelete(Boolean isDelete) {
this.isDelete = isDelete;
}
では、テーブル作成フィールドが is_xxx というネーミングメソッドを使用する場合、対応するエンティティ POJO クラスはどのように定義すればよいでしょうか。永続層フレームワークを使用してマッピングするにはどうすればよいですか?
方法 1: テーブル フィールドに対応する is_xxx 変数は、ブール データ型ではなく整数データ型を使用します。上記のUserオブジェクトで示したように、Integerデータ型のisModifyでは逆解析でisModify変数が取得できないという問題はありません。
方法 2: テーブル フィールドに対応する is_xxx 変数は引き続きブール データ型を使用しますが、POJO クラス変数は is プレフィックスを削除し、xml 構成ファイルで is_xxx から xxx へのマッピング関係を設定します。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="com.example.demo.dao.UserMapper">
<resultMap type="com.example.demo.entity.User" id="userMap">
<result property="id" column="id"/>
<result property="name" column="name"/>
<result property="age" column="age"/>
<result property="name" column="name"/>
<result property="addr" column="addr"/>
<result property="isModify" column="is_modify"/>
<result property="delete" column="is_delete"/>
</resultMap>
</mapper>