在 Spring：使用接口作为 RequestBody 并返回正确的类

Question

我正在尝试在 Spring 控制器中使用接口，但无法实例化正确的类。

我有以下方法：

@RequestMapping(value="/settings/features/{feature}", method=RequestMethod.POST, produces = "application/json; charset=utf-8")
@ResponseBody
public ResponseEntityWrapper setFeatureSettings(
        HttpServletRequest request,
        @PathVariable Feature feature,
        @RequestBody IFeatureSettings featureSettings,
        HttpServletResponse response
        ) {
           ...
        }

我有几个实现 IFeatureSettings 的类，我需要为输入实例化正确的类。我可以通过查看特征（它是一个枚举）来知道哪个是正确的类。因此，对于功能 A，我将拥有 AFeatureSettingsImpl，对于功能 B，我将拥有 BFeatureSettingsImpl。

理想情况下，有一些方法可以在中间说：这一次，用数据填充类 AFeatureSettingsImpl 并将其作为接口实现返回。

我一直在研究 HandlerMethodArgumentResolver，这听起来是正确的方法，但我不知道该怎么做。我需要访问 feature 参数，希望在我得到解决代码之前解决这个问题（或者我需要自己解决它）。

Answer 1

编写另一个以feature 和bodyObject 作为参数的方法怎么样？

类似

private final IFeatureSettings getFeatureImpl(Feature feature, Object bodyObject) {
switch(feature) {
case a: return new AFeatureSettingsImpl;
...
   }
}

顺便说一句，我真的不知道你想要的东西是否存在。

Answer 2

简单的解决方案是在方法签名中使用Map 而不是IFeatureSettings。然后根据您的 Feature 鉴别器，您可以手动实例化和填充 bean。使用Apache BeanUtils 看起来像这样：

@RequestMapping(value="/settings/features/{feature}", method=RequestMethod.POST, produces = "application/json; charset=utf-8")
@ResponseBody
public ResponseEntityWrapper setFeatureSettings(
    HttpServletRequest request,
    @PathVariable Feature feature,
    @RequestBody Map featureSettings,
    HttpServletResponse response) {
        IFeatureSettings bean = createBean(feature); // instantiating the right bean based on the feature discriminator
        BeanUtils.populate(bean, featureSettings);
        ...
}

如果您想让它更通用，请查看 HttpMessageConverters。 Spring 默认使用MappingJacksonHttpMessageConverter 将json 与@RequestBody 绑定。您必须使用自定义逻辑扩展此转换器。请记住，在这种情况下，特征鉴别器不能是独立的参数，因为您需要在转换器中访问它。您可以放入 HTTP 标头以使其工作。转换器的readInternal 方法看起来像：

@Override
protected Object readInternal(Class<?> clazz, HttpInputMessage inputMessage) throws IOException, HttpMessageNotReadableException {
    Class<?> actualClass = lookupByFeature(inputMessage.getHeaders().get("feature")); // returns the actual Class type based on the feature found in the header
    return super.readInternal(actualClass, inputMessage); // and now the original implementation can use the actual type instead of the interface
}