MyBatis-Plus中实体类无参构造的重要性解析

问题背景

在使用MyBatis-Plus进行数据库操作时，开发者可能会遇到一个常见的异常情况：当执行SQL查询时，字符串字段被错误地映射为数字字段，导致NumberFormatException异常。这种情况往往与实体类的构造方式有关。

典型错误表现

从错误日志中可以看到，当MyBatis尝试将查询结果映射到实体类时，系统抛出了NumberFormatException异常。具体表现为：系统试图将一个BCrypt加密的密码字符串"$2a$10$EH1Owe..."转换为数字类型，这显然是不合理的。

根本原因分析

经过深入分析，这个问题的主要原因是实体类缺少无参构造函数。MyBatis/MyBatis-Plus在映射查询结果到Java对象时，有以下两种方式：

1. 通过无参构造函数创建对象：首先调用无参构造函数创建对象实例，然后通过setter方法为各个属性赋值。

2. 通过带参构造函数创建对象：如果实体类中定义了带参数的构造函数，MyBatis会尝试匹配查询结果列与构造函数参数。

当实体类中既没有无参构造函数，又没有正确配置带参构造函数的映射时，MyBatis会尝试自动匹配，可能导致类型映射错误，如将字符串字段误认为数字字段。

解决方案

针对这个问题，有以下几种解决方案：

方案一：添加无参构造函数

最简单的解决方案是在实体类中添加一个无参构造函数：

public class User {
    // 其他字段和方法
    
    public User() {
        // 无参构造函数
    }
}

方案二：正确配置带参构造函数

如果确实需要使用带参构造函数，需要在resultMap中明确指定构造函数映射：

<resultMap id="baseResultMap" type="com.dongmitech.gaspsi.entity.User">
    <constructor>
        <idArg column="id" javaType="java.lang.Long"/>
        <arg column="password" javaType="java.lang.String"/>
        <!-- 其他构造函数参数 -->
    </constructor>
    <!-- 其他属性映射 -->
</resultMap>

方案三：检查实体类定义

确保实体类中的字段类型与数据库中的列类型匹配，特别是像password这样的字段应该定义为String类型而非数值类型。

最佳实践建议

1. 始终提供无参构造函数：即使当前不需要，也为实体类保留无参构造函数，这是MyBatis/MyBatis-Plus的推荐做法。

2. 明确类型映射：在resultMap中为每个字段明确指定jdbcType和javaType，避免自动类型推断可能带来的问题。

3. 保持一致性：确保数据库表结构、实体类定义和映射配置三者之间的类型一致性。

4. 使用Lombok时注意：如果使用Lombok的@AllArgsConstructor注解，记得同时添加@NoArgsConstructor注解。

总结

在MyBatis-Plus开发中，实体类的构造方式直接影响着查询结果的映射过程。缺少无参构造函数可能导致MyBatis采用不恰当的对象创建和属性填充策略，进而引发类型转换异常。遵循框架的最佳实践，明确配置实体类的构造方式，可以避免这类问题的发生，保证数据访问层的稳定性和可靠性。