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

Question

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

1. 将各个参数映射到相应的方法参数：

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

}

1. 将所有参数映射到Java bean的属性：

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

}

第二个选项似乎更具吸引力，因为它允许输入查询参数的验证逻辑从blah方法移动和解耦，其核心职责应该是处理并将验证委托给验证器应该高度解耦（还有SOLID原理，对吧？）。

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

Answer 1

JAX-RS 2.0中引入了@BeanParam注释作为参数聚合器（这意味着它不能在JAX-RS 1.0中使用）。

@BeanParam注释背后的想法是让Java类聚合用@XxxParam注释注释的参数。以下@XxxParam注释可用于注释参数聚合器类的字段：

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

除了注释@XxxParam注释的字段外，参数聚合器类还可以包含使用@Context注释注释的字段。有关可以使用@Context注释注入的类型列表check this answer。

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

但是当你需要在不同的方法中重用参数或者方法有许多参数用@XxxParam注释注释时，请转到@BeanParam方法

在您的问题中，您提到了SOLID principle。但请不要忘记KISS principle：）

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