Mybatis中怎么样确定需要更新的字段？(不要答通过Null或为空判断)

更新一条记录一般都是传入一个Entity实例，然后Sql语句通过主键查找要更新的记录、通过字段为Null或为空判断要更新的字段。
但是，这种做法存在Bug：
例如某人在某个允许为空的字段(例如[家庭住址])填写了内容，然后他想删除掉，于是他在页面上把这个字段的内容清空，然后点保存，然后…他会发现原先的内容居然还在，没有办法清除了！
或许这个实例，大家会说，那本人就只判断Null不判断空好了。
可是，假设这个允许为空的字段是一个日期型呢？我们怎么样判断是要清空这个字段还是保持不变？
或许大家会说，你在前面的业务层肯定能知道是要清空还是要保持不变，但是问题在于，Mapper层要怎么判断呢？判断Null和判断空都不可行了，那么应该怎么判断呢？

解决方案

引用:

把它转换成Entity实例传到后台可能就变成了这样。
用户信息{用户ID:”****”,用户名:nul,密码:null,注册日期:null,姓名:”****”,生日:null,家庭住址:””}

你不会额外创建一个实体类单独用于修改吗？
用户能改哪些就在实体类里创建那些，非得乱七八糟的字段全加上？
假如不想加，那就sql语句限定可以改哪些字段，不让改的就不写进sql Mybatis中怎么样确定需要更新的字段？(不要答通过Null或为空判断)

LZ 的这个问题，是将用户的属性一个一个的封装到Map中，然后传到MyBatis，实现修改。
按照你的需求，并灵活的支持任何字段的修改，你的那个方式是行不通的。
干脆索性就先从数据库中把此用户的信息全部查出来，然后更改用户修改的字段，将最新信息的用户类传到Dao，最后传到MyBatis实现修改。

引用:

Quote: 引用:

Quote: 引用:
把它转换成Entity实例传到后台可能就变成了这样。
用户信息{用户ID:”****”,用户名:nul,密码:null,注册日期:null,姓名:”****”,生日:null,家庭住址:””}

你不会额外创建一个实体类单独用于修改吗？
用户能改哪些就在实体类里创建那些，非得乱七八糟的字段全加上？
假如不想加，那就sql语句限定可以改哪些字段，不让改的就不写进sql

引用:
MyBatis 的SQL是你本人写的，要不要更新，你的SQL说了算。

可是，更新不更新这还真的不是本人的SQL说了算，我们的项目前端和后端是完全独立的，也就意味着，前端可以随时在表单里减少一个字段。

那就说明你还没好好的理解MyBatis是怎么更新数据库的。你的要求除了判断空外，MyBatis里没有其他办法。

<!-- 更新学生信息 -->
<update id="updateStudent" parameterType="StudentEntity">
    UPDATE STUDENT_TBL
    <set>
        <if test="studentName!=null and studentName!="" ">
            STUDENT_TBL.STUDENT_NAME = #{studentName},
        </if>
        <if test="studentSex!=null and studentSex!="" ">
            STUDENT_TBL.STUDENT_SEX = #{studentSex},
        </if>
        <if test="studentBirthday!=null ">
            STUDENT_TBL.STUDENT_BIRTHDAY = #{studentBirthday},
        </if>
        <if test="classEntity!=null and classEntity.classID!=null and classEntity.classID!="" ">
            STUDENT_TBL.CLASS_ID = #{classEntity.classID}
        </if>
    </set>
    WHERE STUDENT_TBL.STUDENT_ID = #{studentID};
</update>

1.这个问题不能在持久层dao中得到解决，首先，dao不应该考虑前端业务的问题
2.那么这个问题就需要业务层来解决，然后你这里其实有个问题，就是不规范，就是完全不清楚前端是
想更新这个空字段呢，还是不想更新，就是假如你业务层提供一个通用的方法，但是由于没有足够清楚的
规范，导致没法判断，所以前端到业务层，需要一个规范，例如你要将这个字段制空，就需要传特殊字符如-1，然后
业务层就可以做成一个通用的东西了，说白了，就是一定要清楚明白前端要做什么，原因是你这里，null和空已经不能
判断前端是要更新呢，还是压根不更新这个字段

本人觉得吧，持久层就不应该考虑这个字段要不要更新或说这个字段该怎么更新，都考虑完了还要逻辑层干嘛？持久层就是一个单纯的与数据库交互的层面，只要考虑怎么与数据库交互，sql语句是不是最优的，有没有可能报错等问题。至于题主说的，例如地址这个字段假如为空该怎么更新这个问题，可以在逻辑层做出一个判断，假如没有值就给这个字段设为空，持久层必然是要做非空验证的，为空就不更新，这样不就解决了吗？而且，本人觉得假如一个用户在页面把地址这个字段给删了，必然是不想保存了，那就直接更新完事，假如业务上不允许删，那就只给客户看，不给操作就可以了