项目中使用 MyBatis（二）

1. 项目中使用 MyBatis（二）

1.1. 获取新插入的数据的id

如果在插入数据时，就需要实时获取新数据的id，首先，在配置XML时，<insert>节点需要添加2个属性的配置：

<insert id="xx" parameterType="xx.xx.xx.xx.User"
	useGeneratedKeys="true"
	keyProperty="id">
</insert>

以上配置中，useGeneratedKeys表示需要获取自动生成的主键（通常都是自动递增的id），keyProperty表示当获取了主键的值（id的值），该值将被封装到哪个属性中，即插入数据时的参数User类型中的id属性！

所以，具体的效果是，当尝试调用Integer reg(User user)方法执行插入时，指定了以上配置后，MyBatis会将新插入的数据的id封装到user参数对象中，所以：

userMapper.reg(user);
System.out.println(user.getId());

1.2. MyBatis中的动态SQL

1.2.1. 概念

MyBatis支持动态SQL，具体的表现是：在配置SQL语句时，可以使用一些简单的逻辑代码，例如if、foreach……使得最终编译出来的SQL语句并不是固定的，而是可能随着参数发生变化的！

1.2.2. 使用foreach一次删除多条数据

一次删除多条数据的SQL语句大致是：

DELETE FROM 表名 WHERE id IN (?,?,?)

而实际应用时，id的列表是由用户进行选取得到的，所以，对于开发者而言，根本就不知道id的列表到底是多少！

针对这样的需求，应该使用动态SQL中的foreach，遍历id列表，得到SQL语句 中例如(?,?,?)这个部分即可。

假设在t_user表中实现这样的操作，首先，还是在接口中声明抽象方法：

Integer delete(List<Integer> ids);

然后，在配置的SQL映射中：

<delete id="delete">
	DELETE FROM 
		t_user 
	WHERE 
		id IN (
			<foreach collection="list" 
				item="id"
				separator=",">
				#{id}
			</foreach>
		)
</delete>

在<foreach>节点中，collection表示需要遍历的目标，可以是List集合，也可以是数据，当该节点对应的方法只有1个参数时，该属性的取值是list或array，当该节点对应的方法的参数超过1个时，该属性的取值是参数的名称（是@Param注解中确定的名称）；item属性是遍历过程中，取出的数据的名称，是自定义的，在<foreach>节点内部也会使用该名称表示变量；seperator表示分隔符，例如以上删除时，SQL中各个id值应该使用逗号分隔，形成例如1,3,5,7这样的格式，则该属性的值为逗号；还有open和close属性，用于配置整个遍历出来的结果的前缀和后缀，例如在编写SQL语句时没有指定IN关键字后面的括号时，可以添加open="(" close=")"这2项配置。

1.2.3. 使用if选择性的更新数据

在有些更新数据的场景里，可能存在：一次性可以更新同一个用户的多项属性数据，但是，如果没有提交其中的某个数据，则该数据不发生变化！例如：在修改个人资料页面中，还可以有“新密码”输入框，如果不想修改密码，则不填写即可。

针对这样的应用需求，可以添加抽象方法：

Integer changeInfo(User user);

然后，配置SQL映射：

UPDATE 
	t_user 
SET 
	<if test="password != null">
	password=#{password},
	</if>
	phone=#{phone},
	email=#{email},
	birthday=#{birthday} 
WHERE 
	id=#{id}

2. 业务

2.1. 定位

在MVC的程序设计中，把整个项目的核心划分出了M、V、C这3大部分。

其中，V表示View，即视图，通常指的是HTML或JSP文件，用于显示界面，为用户提供操作入口，用户可以在界面进行点击、输入、选择等操作；

而C表示Controller，即控制器，在原生的JavaEE技术中，指的是Servlet，在SSM框架中，指的是Controller类，主要作用是接收请求，并给予响应，但是，对数据本身并不作实质的处理；

还有M表示Model，即数据模型，具体的指对数据的处理操作，为了更加明确的划分数据的逻辑与执行的操作，所以，在实际编程时，Model表现为Service和Dao/Mapper的组合，其中，Service用于处理业务，而Dao/Mapper处理数据的增删改查；

因此，定位为Service的类，通常称之为业务逻辑类，主要用于设计业务的流程与逻辑，即：什么时候允许做什么、先做什么再做什么……

有了业务逻辑后，更加易于保证数据的安全。

有了业务逻辑后，持久层（Dao/Mapper）也就不再关心业务，只是单纯的实现增删改查即可，而不用考虑能不能增加或修改或删除等。

2.2. 用户注册的业务

2.2.1. 分析业务逻辑

用户注册中就可以有：用户名必须是唯一的，如果尝试注册的用户名已经被占用，则不允许注册！

2.2.2. 实现

首先，持久层（DAO/Mapper）必须具备：根据用户名查询用户信息，以判断某个用户名是否被占用；注册，将用户数据添加到数据表中。

然后，创建业务接口com.company.mybatis.service.IUserService，并添加抽象方法：

public interface IUserService {

	User reg(User user);

}

接下来，创建以上接口的实现类com.company.mybatis.service.impl.UserServiceImpl，后续对应的查询、注册功能都需要通过持久层（UserMapper）来完成，所以，在这个类中，需要UserMapper的对象，可以声明为成员变量，然后通过Spring为其自动装配来注入值，当然，要使用自动装配机制，首先得保证整个类（UserServiceImpl）是能够被Spring管理的，所以，当前类还需要添加@Service注解，并且，在Spring的配置文件中开启组件扫描，要能够扫到当前类所在的包！

然后再实现以上抽象方法：

@Service("userService")
public class UserServiceImpl implements IUserService {
	
	@Autowired
	private UserMapper userMapper;

	public User reg(User user) {
		// 根据user.getUsername()查询用户信息
		String username = user.getUsername();
		User result
			= userMapper.getUserByUsername(username);
		// 判断查询结果是否为null
		if (result == null) {
			// 是：没有被占用，则允许注册
			userMapper.reg(user);
			// 返回
			return user;
		} else {
			// 否：已经被占用，则不允许注册
			throw new RuntimeException(
				"您尝试注册的用户名(" + username + ")已经被占用！");
		}
	}

}

最后，测试：

public class TestUserService {
	
	@Test
	public void reg() {
		// 加载Spring的配置文件，获取Spring容器
		AbstractApplicationContext ac
			= new ClassPathXmlApplicationContext(
				"spring-service.xml", "spring-dao.xml");
		
		// 获取所需的对象：IUserService
		IUserService service
			= ac.getBean("userService", IUserService.class);
		
		// 测试执行
		try {
			User user = new User("苍教师", "123456");
			User result = service.reg(user);
			System.out.println("注册成功：" + result);
		} catch (RuntimeException e) {
			System.out.println("注册失败：" + e.getMessage());
		}
		
		// 释放资源
		ac.close();
	}

}

2.3. 用户登录的业务

2.3.1. 分析

用户需要提交用户名、密码才可以登录，在验证时，应该根据用户名查询用户信息，如果存在，则验证用户输入的密码，与刚才查询结果中的密码是否匹配，如果还能够匹配，则登录成功，如果用户名匹配的数据不存在，或密码不匹配，则登录失败。

2.3.2. 实现登录验证

在IUserService接口中添加新的抽象方法，表示用户登录：

User login(String username, String password);

首先，方法名可以是简单易懂的，使用login即可，方法参数取决于用户提交的数据，或必要的数据，则可以是String username, String password，返回值只考虑登录成功后所需要得到的结果，则设计为User类型，后续，当控制器（Controller）调用这个方法，并且成功登录后，可以通过该返回值获取到当前用户的id、用户名甚至头像等等数据，存放到Session中，以用于判断用户已经登录及显示相关数据！

在设计业务层的方法时，返回值应该使用“操作正确时返回的结果”，而不参考可能出现的业务错误来设计返回值。关于失败的处理，统一使用抛出异常来解决！

为了保证抛出多种异常能形成程序中的分支，应该为不同错误创建不同的异常类，也就是需要自定义异常，例如：UserNotFoundException、PasswordNotMatchException，这些异常都应该存放于业务包的ex子包中，同时，为了便于统一处理异常（至于是仔细处理还是统一处理，都是控制器决定，在写业务层，应该为各种做法都提供基础）还自定义一个ServiceException，作为当前项目中所有的业务层可能抛出的异常的基类，并且是继承自RuntimeException的。

然后，在UserServiceImpl实现类中实现以上方法：

public User login(String username, String password) {
	// 根据用户名查询用户信息
	// 判断与用户名匹配的用户信息是否存在
	// 是：存在，判断参数密码和查询到的用户信息中的密码是否匹配
	// -- 是：匹配，登录成功，将查询到的用户信息作为返回值
	// -- 否：不匹配，抛出异常：密码错误
	// 否：不存在，抛出异常：用户名不存在
}

2.4. 暂时小结

• 业务逻辑类，主要用于设计业务的流程与逻辑，即：什么时候允许做什么、先做什么再做什么……

• 在设计业务层的方法时，返回值应该使用“操作正确时返回的结果”，而不参考可能出现的业务错误来设计返回值。关于失败的处理，统一使用抛出异常来解决！

• 应该创建ServiceException类表示当前项目的业务异常的基类，当前项目中所有的业务异常都应该是这个类的子孙类！

• 在业务方法的实现中，凡是认定为“错误”或“失败”，均抛出对应的异常对象，并在抛出的对象描述错误信息，如果没有合适的异常类，则创建新的异常类即可！

其它

1. 可变参数

可变参数，表示当调用某个方法时，使用的参数的数量是不确定的，是可能发生变化的，例如：

public class TestSample {

	public static void main(String[] args) {
		sum();
		sum(1);
		sum(1, 2);
		sum(1, 2, 3);
		sum(1, 2, 3, 4);
		sum(1, 2, 3, 4, 5);
		sum(1, 2, 3, 4, 5, 6);
		sum(1, 2, 3, 4, 5, 6, 7);
	}

	public static void sum(int... numbers) {
		int result = 0;
		for (int i = 0; i < numbers.length; i++) {
			result += numbers[i];
		}
		System.out.println(result);
	}

}

在声明方法时，可变参数使用数据类型... 参数名来表示，例如：

public static void sum(int... numbers)

在方法体中，处理该参数时，把参数视为数组即可。

在调用方法时，可变参数的数量最少是0个，即可以不提供任何参数。

注意：每个方法中最多只允许存在1个可变参数，且可变参数必须是该方法的最后一个参数！