Настроить параметры запроса на отображение и поля внутри DTO?

Question

У меня есть следующий класс:

public class MyDTO { 

     private String kiosk; 
     ... 
} 

и следующий URL:

http://localhost:1234/mvc/controllerUrl?kiosk=false 

и следующий метод контроллера:

@RequestMapping(method = RequestMethod.GET, produces = APPLICATION_JSON) 
@ResponseBody 
public ResponseEntity<List<?>> getRequestSupportKludge(final MyDTO myDTO, BindingResult bindingResult) { 
    ... 
} 

Сейчас он работает хорошо и логическое поле решает правильно.

Теперь URL параметр изменился следующим образом:

http://localhost:1234/mvc/controllerUrl?new_kiosk=false 

Я не хочу, чтобы изменить имя параметра внутри DTO. Есть ли способ сказать весной понять, что new_kiosk значение параметра запроса должно быть помещено в поле kiosk?

Answer 1

Помимо установки дополнительного сеттера, вы можете передать дело, создав настраиваемый аргумент. Есть несколько способов сделать это, но уже есть хорошо обсужденный post. Если бы я был вами, я бы сосредоточился на ответе jkee. Следуйте шаг за шагом, и чем все, что вам нужно сделать, это аннотировать DTO с чем-то вроде,

public class MyDTO { 

     @ParamName("new_kiosk") 
     private String kiosk; 
     ... 
} 

Обратите внимание, что даже если вы не можете изменить MyDTO класс, вы все еще можете следовать маршрутом пользовательского распознавателя. В этом post я ответил, как вы можете написать аннотацию типа параметра. Объединяя два сообщения, вы можете легко создать аннотацию, например. @ParamMapper, который будет определять сопоставление от запроса к свойствам. Вспомните что-то вроде

getRequestSupportKludge(@ParamMapper("new_kiosk;kiosk") MyDTO myDTO, BindingResult bindingResult) 

Answer 2

Там разные способы сделать это.

Если вы можете изменить MyDTO класс, самый простой способ, чтобы добавить сеттер как это было предложено M.Deinum:

public class MyDTO { 

     private String kiosk; 
     ... 
     public void setNew_kiosk(String kiosk) { 
      this.kiosk = kiosk; 
     } 
} 

Таким образом, вы можете обрабатывать http://localhost:1234/mvc/controllerUrl?kiosk=false, а также http://localhost:1234/mvc/controllerUrl?new_kiosk=false

Если вы (поскольку DTO является частью библиотеки, которую вы не можете изменить или ...), вы можете использовать фильтр, сопоставленный с /mvc/controllerUrl, который будет обертывать запрос с помощью настраиваемого HttpServlerRequestWrapper, который переопределит следующие методы:

String getParameter(String name) 
Map<String,String[]> getParameterMap() 
Enumeration<String>  getParameterNames() 
String[] getParameterValues(String name) 

, вызывающий базовые методы запроса и обрабатывающие имя специального параметра. Пример:

String[] getParameterValues(String name) { 
    String[] values = req.getParameterValues(name); // req is the wrapped request 
    if ("kiosk".equals(name) && (values == null) { // will accept both names 
     values = req.getParameterValues("new_kiosk"); // try alternate name 
    } 
    return values; 
} 

Это будет гораздо труднее писать и тестировать, так только идти по этому пути, если вы не можете изменить MyDTO класс.

Вы также можете попытаться использовать пользовательскую реализацию WebBindingInitializer.От Spring Framework Reference Manual:

экстернализовать связывания инициализации данных, вы можете обеспечить собственную реализацию интерфейса WebBindingInitializer, который затем включить путем подачи пользовательской конфигурации боб для AnnotationMethodHandlerAdapter, тем самым перекрывая конфигурацию по умолчанию.

Опасайтесь: рекомендуется использовать это для регистрации пользовательских редакторов для целого приложения - не для вашего использования. И Spring Framework изнутри описывается как легко расширяется, но не переопределяет. Пусть покупатель будет бдителен ...

Резюме: попробуйте использовать метод 1, если вы не можете, а затем использовать method2, и только попробуйте method3, если у вас есть другие причины, чтобы использовать пользовательские WebBindingInitializer