验证

前  端： 提交一份用户数据（姓名:某, 性别:男, 爱好:女, 签名:xxx, 手机:xxx, 邮箱:null）
控制器： 发现邮箱是空的，抛ValidationException("邮箱没填")
前  端： 已修改，重新提交
安  全： 发送验证码时发现手机号少一位，抛RemoteInvokeException("无法发送验证码")
前  端： 已修改，重新提交
服务层： 邮箱怎么有重复啊，抛BusinessRuntimeException("不允许开小号")
前  端： 已修改，重新提交
持久层： 签名字段超长了插不进去，抛SQLException("插入数据库失败，SQL：xxx")
…… ……
前  端： 你们这些坑管挖不管埋的后端，各种异常都往前抛！
用  户： 这系统牙膏厂生产的？

• 在 Controller 层做，在 Service 层不做。理由是从 Service 开始会有同级重用，出现 ServiceA.foo(params)调用 ServiceB.bar(params)时，就会对 params 重复校验了两次。
• 在 Service 层做，在 Controller 层不做。理由是无业务含义的格式校验已在前端表单验证处理过，有业务含义的校验，放在 Controller 层无论如何不合适。
• 在 Controller、Service 层各做各的。Controller 做格式校验，Service 层做业务校验，听起来很合理，但这其实就是上面段子中被嘲笑的行为。
• 还有其他一些意见，譬如还有提在持久层做校验，理由是这是最终入口，把守好写入数据库的质量最重要。

• 对于无业务含义的格式验证，可以做到预置。
• 对于有业务含义的业务验证，可以做到重用，一个 Bean 被用于多个方法用作参数或返回值是很常见的，针对 Bean 做校验比针对方法做校验更有价值。利于集中管理，譬如统一认证的异常体系，统一做国际化、统一给客户端的返回格式等等。
• 避免对输入数据的防御污染到业务代码，如果你的代码里面如果很多下面这样的条件判断，就应该考虑重构了：

  // 一些已执行的逻辑
  if (someParam == null) {
  	throw new RuntimeExcetpion("客官不可以！")
  }
  

• 利于多个校验器统一执行，统一返回校验结果，避免用户踩地雷、挤牙膏式的试错体验。

@Null、@NotNull、@AssertTrue、@AssertFalse、@Min、@Max、@DecimalMin、@DecimalMax、@Negative、@NegativeOrZero、@Positive、@PositiveOrZeor、@Szie、@Digits、@Pass、@PastOrPresent、@Future、@FutureOrPresent、@Pattern、@NotEmpty、@NotBlank、@Email

/**
* 创建新的用户
*/
@POST
public Response createUser(@Valid @UniqueAccount Account user) {
	return CommonResponse.op(() -> service.createAccount(user));
}
/**
* 更新用户信息
*/
@PUT
@CacheEvict(key = "#user.username")
public Response updateUser(@Valid @AuthenticatedAccount @NotConflictAccount Account user) {
	return CommonResponse.op(() -> service.updateAccount(user));
}

• @UniqueAccount：传入的用户对象必须是唯一的，不与数据库中任何已有用户的名称、手机、邮箱产生重复。
• @AuthenticatedAccount：传入的用户对象必须与当前登录的用户一致。
• @NotConflictAccount：传入的用户对象中的信息与其他用户是无冲突的，譬如将一个注册用户的邮箱，修改成与另外一个已存在的注册用户一致的值，这便是冲突。

public static class AuthenticatedAccountValidator extends AccountValidation<AuthenticatedAccount> {
    public void initialize(AuthenticatedAccount constraintAnnotation) {
        predicate = c -> {
            AuthenticAccount loginUser = (AuthenticAccount) SecurityContextHolder.getContext().getAuthentication().getPrincipal();
            return c.getId().equals(loginUser.getId());
        };
    }
}
public static class UniqueAccountValidator extends AccountValidation<UniqueAccount> {
    public void initialize(UniqueAccount constraintAnnotation) {
        predicate = c -> !repository.existsByUsernameOrEmailOrTelephone(c.getUsername(), c.getEmail(), c.getTelephone());
    }
}
public static class NotConflictAccountValidator extends AccountValidation<NotConflictAccount> {
    public void initialize(NotConflictAccount constraintAnnotation) {
        predicate = c -> {
            Collection<Account> collection = repository.findByUsernameOrEmailOrTelephone(c.getUsername(), c.getEmail(), c.getTelephone());
            // 将用户名、邮件、电话改成与现有完全不重复的，或者只与自己重复的，就不算冲突
            return collection.isEmpty() || (collection.size() == 1 && collection.iterator().next().getId().equals(c.getId()));
        };
    }
}

/**
 * 表示一个用户的信息是无冲突的
 *
 * “无冲突”是指该用户的敏感信息与其他用户不重合，譬如将一个注册用户的邮箱，修改成与另外一个已存在的注册用户一致的值，这便是冲突
 **/
@Documented
@Retention(RUNTIME)
@Target({FIELD, METHOD, PARAMETER, TYPE})
@Constraint(validatedBy = AccountValidation.NotConflictAccountValidator.class)
public @interface NotConflictAccount {
    String message() default "用户名称、邮箱、手机号码与现存用户产生重复";
    Class<?>[] groups() default {};
    Class<? extends Payload>[] payload() default {};
}

public class Account extends BaseEntity {
	@NotEmpty(message = "用户不允许为空")
    private String username;
    @NotEmpty(message = "用户姓名不允许为空")
    private String name;
    private String avatar;
    @Pattern(regexp = "1\\d{10}", message = "手机号格式不正确")
    private String telephone;
    @Email(message = "邮箱格式不正确")
    private String email;
}