Map的野路子
首先有一张user数据表，数据库名称为mybatis，数据如下：
我们使用以下两种方式实现数据更新的操作。
方式一
UserMapper.java如下：
/**
* @description: 更改用户
* @Param: [user]
* @Return: int
*/
int updateUser(User user);
UserMapper.xml如下：
<update id="updateUser" parameterType="com.th.pojo.User">
update mybatis.user set name =#{name},pwd=#{pwd} where id=#{id};
</update>
java测试类如下：
/**
* @description: 通过对象来更新数据
* @Param: []
* @Return: void
*/
@Test
public void testUpdateUser(){
SqlSession sqlSession = MybatisUtils.getSqlSession();
try {
UserMapper mapper = sqlSession.getMapper(UserMapper.class);
int i = mapper.updateUser(new User(4, "燕gg", "YYYY"));
if (i>0){
System.out.println("Update Successful");
}
sqlSession.commit();
} catch (Exception e) {
e.printStackTrace();
} finally {
sqlSession.close();
}
}
实验结果如下：
数据成功进行了更改，现在，在更改的基础上继续使用方式二再进行更改。
方式二
UserMapper.java如下：
/**
* @description: 用Map的方式更新数据
* @Param: [map]
* @Return: int
*/
int updateUser2(Map<String,Object> map);
UserMapper.xml如下：
<update id="updateUser2" parameterType="map">
update mybatis.user set name =#{userName} where id=#{userid};
</update>
java测试类如下：
/**
* @description: 使用map方式传递参数，只需要传递需要的参数就可以
* @Param: []
* @Return: void
*/
@Test
public void testUpdateUser2(){
SqlSession sqlSession = MybatisUtils.getSqlSession();
try {
UserMapper mapper = sqlSession.getMapper(UserMapper.class);
Map<String, Object> map = new HashMap<>();
map.put("userid", 4);
map.put("userName", "燕g");
int i = mapper.updateUser2(map);
if (i>0){
System.out.println("Update Successful");
}
sqlSession.commit();
} catch (Exception e) {
e.printStackTrace();
} finally {
sqlSession.close();
}
}
实验结果如下：
我们同样正确地对数据进行了修改。
两种方式很显然都能达到修改数据的目的，在第一种方式这里，我们在SQL语句中传入的是一个User对象作为参数，
name、pwd、id分别对应User实体类的三个属性，这是Mybatis帮我们做的。既然传入的是一个完整的User对象，那么我们必须创建一个User对象，这就出现了一个问题，当我们只需要修改其中一个属性时，就像例子中，我只要修改一个name属性时，那我同样需要创建一个完整的对象。更扯的其他不需要修改的属性必须保持与原来保持一致，否则一不留神也会被更改。这还只是有三个属性，如果对一个有很对属性的对象进行修改呢？这样的方式显然就很繁琐。
而对于方式二，我们不再需要一个完整的对象，我们只需要通过键值对将要修改的属性进行修改。通过传递的map对象，在SQL语句中直接使用键名就可以了；就像在上面例子中，我们通过
id对name属性进行修改，我们只需要设置两个存储id对name属性的键值对就可以了。这在大量属性但只需要我们修改个别少数属性时就简单了很多。当然，这种野路子并非完全没有缺点，它在处理不同业务时需要的SQL语句是会更多的。
