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

2022-09-03 01:04:58

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

  1. 将各个参数映射到相应的方法参数:
@GET
public String blah(@QueryParam("testParam") String testParam) {

}
  1. 将所有参数映射到 Java Bean 的属性:
@GET
public String blah(@BeanParam RequestParamBean bean) {

}

第二个选项似乎更具吸引力,因为它允许将输入查询参数的验证逻辑与方法移动和分离,该方法的核心职责应该是处理并将验证委托给验证者,应该高度解耦(以及SOLID原则,对吧?)。blah

但是,我看到的大多数示例(实际上是我正在处理的现有项目)仅使用第一个选项。我想知道是否有任何理由不广泛使用第二个选项?有什么陷阱吗?这是反模式吗?这是否违反任何最佳实践?


答案 1

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


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

除了对批注进行批注的字段之外,参数聚合器类还可以具有使用@Context批注进行批注的字段。有关可与@Context批注一起注入的类型列表,请检查此答案@XxxParam


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

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


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

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


答案 2

推荐