JavaEE字段验证最佳实践咨询：新手EJB参数验证优化方案

兄弟，完全懂你这种把参数校验硬塞进EJB里的糟心感受——代码越写越冗余，每次加新接口都要复制粘贴一堆if-else，既违背了单一职责，后期维护起来也头大。结合JavaEE的生态，给你分享几个经过实践检验的参数验证最佳实践：

1. 用JSR-380（Bean Validation 2.0）做声明式验证 #

这是JavaEE体系里最标准、最省心的方案，不用写硬编码的校验逻辑，直接给实体类或方法参数加注解就行，容器会自动帮你完成校验。

比如先给请求参数类加校验注解：

public class UserRequest {
    @NotNull(message = "用户名不能为空")
    @Size(min = 3, max = 20, message = "用户名长度需在3-20字符之间")
    private String username;
    
    @Email(message = "邮箱格式不符合要求")
    private String email;
    
    // getter/setter省略
}

然后在EJB的方法参数上加上@Valid注解，校验逻辑就完全交给容器处理了：

@Stateless
public class UserService {
    public void createUser(@Valid UserRequest request) {
        // 这里直接处理业务逻辑就行，不用再写校验代码
    }
}

如果校验不通过，容器会抛出ConstraintViolationException，你可以写一个全局的ExceptionMapper统一处理异常返回，避免每个方法都重复捕获异常。

2. 复杂验证抽成自定义校验注解 #

如果有些校验逻辑没法用现成注解实现（比如校验密码和确认密码是否一致、校验字段值是否符合业务规则），可以自己写自定义注解来封装逻辑，实现复用。

比如先定义注解：

@Target({TYPE, ANNOTATION_TYPE})
@Retention(RUNTIME)
@Constraint(validatedBy = PasswordMatchValidator.class)
public @interface PasswordMatch {
    String message() default "密码与确认密码不匹配";
    Class<?>[] groups() default {};
    Class<? extends Payload>[] payload() default {};
}

再实现具体的校验逻辑：

public class PasswordMatchValidator implements ConstraintValidator<PasswordMatch, UserRequest> {
    @Override
    public boolean isValid(UserRequest request, ConstraintValidatorContext context) {
        return request.getPassword() != null 
                && request.getPassword().equals(request.getConfirmPassword());
    }
}

最后给UserRequest类加上@PasswordMatch注解即可，复杂逻辑被封装起来，不会污染EJB的业务代码。

3. 分层验证：把校验放在API层而非EJB #

如果你的后端不是直接对接前端（比如对接其他服务），建议把校验逻辑放在API入口层（比如JAX-RS的资源类），让EJB只专注于核心业务逻辑，职责划分更清晰：

@Path("/users")
public class UserResource {
    @Inject
    private UserService userService;
    
    @POST
    public Response createUser(@Valid UserRequest request) {
        userService.createUser(request);
        return Response.ok().build();
    }
}

这样EJB里完全看不到校验代码，只负责处理业务，后期修改校验规则也不用动EJB的代码。

4. 用CDI拦截器统一处理零散参数校验（可选） #

如果遇到参数不是实体类，而是零散的基本类型（比如单个String、Integer），没法用Bean Validation的场景，可以写一个CDI拦截器，在调用EJB方法前统一做校验：

@InterceptorBinding
@Target({TYPE, METHOD})
@Retention(RUNTIME)
public @interface ValidateParameters {}

@Interceptor
@ValidateParameters
public class ParameterValidationInterceptor {
    @AroundInvoke
    public Object validate(InvocationContext ctx) throws Exception {
        Object[] parameters = ctx.getParameters();
        // 示例：校验第一个参数不能为空
        if (parameters[0] == null) {
            throw new IllegalArgumentException("必填参数不能为空");
        }
        return ctx.proceed();
    }
}

然后给需要校验的EJB方法加上@ValidateParameters注解，就能复用校验逻辑了。

总结一下，核心思路就是把校验逻辑从EJB中彻底剥离，用声明式注解、分层处理或拦截器的方式实现，让EJB只专注于业务逻辑，避免代码重复和职责混乱。

内容的提问来源于stack exchange，提问作者Maxime Flament