我正在考虑用于处理查询/请求参数的两个选项：
@GET
public String blah(@QueryParam("testParam") String testParam) {
}
@GET
public String blah(@BeanParam RequestParamBean bean) {
}
第二个选项似乎更具吸引力，因为它允许将输入查询参数的验证逻辑与blah方法的移动和解耦，该方法的核心职责应该是处理，并将验证委托给验证者，如果高度去耦（以及SOLID原理，对？）。
但是，我看到的大多数示例（实际上是我正在研究的现有项目）仅使用第一个选项。我想知道第二种选择没有得到广泛使用的原因是什么？有陷阱吗？这是反模式吗？这违反任何最佳做法吗？
该@BeanParam注释在JAX-RS 2.0中作为参数聚合器引入（这意味着它不能在JAX-RS 1.0中使用）。
@BeanParam批注背后的想法是要有一个Java类来聚合带有@XxxParam批注的参数。以下@XxxParam注释可用于注释参数聚合器类的字段：
除了带注释的字段外@XxxParam，参数聚合器类还可以具有带@Context注释的字段。有关可以使用@Context注释注入的类型的列表，请检查此答案。
我相信这只是开发人员的便利和偏好问题。在许多情况下，不需要用于聚集参数的类。@XxxParam在方法参数中使用注释非常方便。
但是，当您需要在不同的方法中重用参数，或者该方法有许多带有@XxxParam注释的参数时，请采用该@BeanParam方法。
在您的问题中，您提到了SOLID原则。但是不要忘了KISS原则 :)
从@XxxParam方法参数中的注释开始，不要过度使用@BeanParam注释来解决您没有的问题。如果需要，您始终可以重构代码以创建参数聚合器类。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句