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语句是会更多的。