我应该在JAX-RS中使用@QueryParam还是@BeanParam？

Question

我在考虑处理查询/请求参数的两个选项:

1. 将各个参数映射到对应的方法参数:

@GET
public String blah(@QueryParam("testParam") String testParam) {

}

2. 将所有参数映射到Java bean的属性:

@GET
public String blah(@BeanParam RequestParamBean bean) {

}

第二个选项看起来更具吸引力,因为它允许输入查询参数的验证逻辑被移动和解耦,blah其核心职责应该是处理并将验证委托给验证器进行高度解耦(以及SOLID原则,正确) ？).

但是,我看到的大多数示例(事实上,我正在处理的现有项目)只使用第一个选项.我想知道为什么没有广泛使用第二种选择是否有任何理由？有任何陷阱吗？这是反模式吗？这是否违反任何最佳做法？

Answer 1

该@BeanParam注释在JAX-RS 2.0作为引入参数聚合器(这意味着它不能在JAX-RS 1.0中使用).

@BeanParam注释背后的想法是使用Java类来聚合使用@XxxParam注释注释的参数.以下@XxxParam注释可用于注释参数聚合器类的字段:

• @CookieParam
• @FormParam
• @HeaderParam
• @MatrixParam
• @PathParam
• @QueryParam

除了注释注释的字段之外@XxxParam,参数聚合器类可以具有用@Context注释注释的字段.有关可以使用@Context注释注入的类型列表,请查看此答案.

我认为这只是开发人员的方便和偏好的问题.在许多情况下,不需要聚合参数的类.@XxxParam在方法参数中使用注释非常方便.

但是当您需要在不同方法中重用参数或者该方法有许多带@XxxParam注释的参数时,请选择该@BeanParam方法.

在您的问题中,您提到了SOLID原则.但不要忘记KISS原则 :)

从@XxxParam方法参数中的注释开始,不要过度使用@BeanParam注释来尝试解决您没有的问题.如果需要,您始终可以重构代码以创建参数聚合器类.