关于表变动而导致的实体变动问题

因为表变动而导致的实体变动问题，出现这种情况较多的是版本迭代的时候。

项目开发初期，表变动导致的代码改动量相对较小，改动后出现的问题也比较少。而在项目迭代的过程中，因为项目已经成型，大部分代码的逻辑和用法都已固定。此时表变动将有可能导致大量业务逻辑代码不可用。

这篇文章就说说因为表变动而需要修改的代码部分。

在此之前先说两个修改代码的小诀窍。

修改代码的诀窍

诀窍一：

如果你用的开发工具是 IDEA 的话，你可以选中类名，然后按下 shift + F6 ，这时候会出现修改类名的对话框。在此处修改类名，将会把项目中有项目引用的地方一起修改。这个方法不仅方便，而且可以使你知道哪些地方的代码受到影响。

修改类名的对话框如下图：

诀窍二：

如果你用的开发工具是 IDEA 的话，当你删除类的时候会弹出如下对话框：

选择“Safe delete(with usage search)”，点击“OK”，此时会出现如下对话框：

点击“View Usages”，此时会出现如下对话框：

你将看到因为删除类而产生的影响，即该类在哪些地方被引用了。

因表变动而导致的实体变动有以下几种修改方式：

说明：以下说明采用的示例均为原表是 User，现改为 BaseUser。

方式一：

先创建新表的实体类，然后删除旧表的实体类，即创建完 BaseUser 的实体之后，直接删除 User 实体。之后通过开发工具的报错信息，或者项目启动时候的报错，对项目中受到影响的代码进行修改。

开发工具的报错信息如下图：

项目启动时候的报错信息如下图：

优点：

能够快速定位受到影响的代码位置。

缺点：

代码改动量大。
由于旧实体的删除而导致代码逻辑理解错误。
无法短时间内启动项目，必须把代码一次性改好。

方式二：

先创建新表的实体类，然后找出引用该实体相关代码将新旧实体进行替换，等全部替换完后再进行旧代码的删除。

优点：

可以短时间内对修改过的代码进行调试。
原业务逻辑都在，在修改代码时可以参考。

缺点：

在删除旧实体之前，容易遗漏受到影响的代码，从而导致项目开发进度受到影响（这个影响可大可小）。

方式三：

创建新表实体类，同时创建新表实体类的service、mapper等相关文件，之后将旧实体类的相关代码迁移到新表实体类的相关代码中。即同时 BaseUser 、BaseUserController、IBaseUserService、BaseUserServiceImpl、BaseUserMapper、BaseUserMapper.xml，之后将 User 、UserController、IUserService、UserServiceImpl、UserMapper、UserMapper.xml 的相关代码迁移到之前创建的代码中。

优点：

可以短时间内对修改过的代码进行调试。
原业务逻辑都在，在修改代码时可以参考。

缺点：

在删除旧实体之前，容易遗漏受到影响的代码，从而导致项目开发进度受到影响（这个影响可大可小）。
代码修改量大

方式四：

将旧实体类的表映射直接替换为新表的映射，即将原来的 @TableName(“USER”) 修改为 @TableName(“BASE_USER”)，同时将旧表实体的属性改为新表实体的属性。具体修改方式如下：

@EqualsAndHashCode(callSuper = true)
@TableName("BASE_USER")
@Data
public class User extends Model<User> {
    /**
     * 用户ID
     */
    @TableId(value = "ID",type = IdType.AUTO)
    private Integer id;
    /**
     * 用户名
     */
    @TableField("NAME")
    private String name;
    ......
}

优点：

在表字段修改不多的情况下，此种方法代码改动量最小。
可以短时间内对修改过的代码进行调试。

缺点：

由于旧实体的变动而导致代码逻辑理解错误。

综合以上四个方法，第四个方法相对较好
在表字段修改不多的情况下，此种方法代码改动量最小。
2. 可以短时间内对修改过的代码进行调试。

缺点：

由于旧实体的变动而导致代码逻辑理解错误。

综合以上四个方法，第四个方法相对较好