Итак, мы подошли к тому моменту в нашем приложении Spring, где нам нужно решить, как обрабатывать представления и согласовывать контент. Ранее мы поддерживали только один конкретный тип контента в наших конечных точках.
Я собираюсь бросить наши, как мне кажется, наши три подхода.
Мой вопрос: Какой из них обычно считается наилучшей практикой / минимальное количество обслуживания? Мы стремимся к твердому соглашению, которому необходимо следовать в нашем приложении, которое может быть нарушено при необходимости, чтобы обеспечить гибкость при желании.
Первый подход:
Используйте ContentNegotiatingViewResolver. Это может включать отображение, определенное в файле сервлета ... в контроллере, каждое действие контроллера должно было бы явно установить объект на карте, используя некоторую магическую строку. Действие контроллера вернет строку, которая ссылается на имя шаблона ... вроде как:
@RequestMapping(value = "/someMapping/source", method = RequestMethod.GET)
public String foo(Model model)
{
// more stuff here
model.addAttribute(SOME_MODEL_KEY, new ArrayList<String>() { "hello world"});
return "someDummyJsonString";
}
Недостатки:
Средство распознавания представлений кажется немного громоздким ... у них есть приоритеты, вам нужно часто переопределять их и т. Д. Кроме того, мне не нравится идея "магических строк", которые используются для ссылки на имена шаблонов / представлений bean.
Второй подход:
Я думаю, что это новое в Spring 3.0, но в RequestMapping вы можете сопоставить заголовки ... так что вы можете сопоставить заголовок Accept следующим образом:
@RequestMapping(value="/someMapping", method = RequestMethod.GET, headers="Accept=application/json")
public @ResponseBody SomeBar foo()
{
// call common controller code here
return buildBar();
}
@RequestMapping(value="/someMapping", method = RequestMethod.GET, headers="Accept=text/xml")
public String foo(Model model)
{
model.addAttribute("someModelName", this.buildBar());
return "someTemplateNameProcessedByViewResolver";
}
SomeBar buildBar()
{
return new SomeBar();
}
Недостатки:
Может быть недостаточно гибким? Я не уверен, но я думаю, что мне действительно нравится подход headers ... Я видел, как другие фреймворки (RESTLet, Rails) используют нечто подобное.
Третий подход:
Третий подход заключается в создании пользовательского View, который будет согласовывать содержимое на основе заголовка Accept и передавать модель соответствующим методом. Это представление согласования содержимого должно знать шаблон и загружать шаблон и т. Д.
@RequestMapping(value="/someMapping", method = RequestMethod.GET, headers="Accept=text/xml")
public View foo()
{
SomeBar bar = new SomeBar();
ContentNegotiatingView view = new ContentNegotiatingView(bar, "templateName");
return return view;
}
Недостатки:
Кажется, что в этом случае представление делает слишком много ... представление будет смотреть на заголовки и устанавливать само тело ответа. Может также потребоваться установить статусы http.
Итак, извините за стену текста, дайте мне знать ваши мысли по этому поводу. Спасибо