Ответ
В Spring MVC контроллер возвращает имя представления (View) в виде строки. Механизм ViewResolver затем сопоставляет это имя с конкретным шаблоном (JSP, Thymeleaf, FreeMarker) для рендеринга.
Типичный поток работы:
- Запрос поступает в метод контроллера, аннотированный
@GetMapping,@PostMappingи т.д. - Контроллер обрабатывает параметры, вызывает сервисный слой (бизнес-логику) и помещает результаты в объект
Model. - Контроллер возвращает
Stringс именем представления. ViewResolverнаходит физический файл шаблона по этому имени (например, в/WEB-INF/views/).- Движок шаблонов рендерит представление, подставляя данные из
Model, и отправляет HTML клиенту.
Пример с Thymeleaf:
@Controller
public class GreetingController {
@GetMapping("/greet")
public String showGreeting(Model model) {
// Добавляем атрибут в модель для передачи в представление
model.addAttribute("message", "Hello, Spring MVC!");
// Возвращаем логическое имя представления.
// ViewResolver преобразует 'greetPage' в '/WEB-INF/views/greetPage.html'
return "greetPage";
}
}Ключевые моменты:
- Для REST API (возврат JSON) используется
@RestController(комбинация@Controller+@ResponseBody). - Можно явно возвращать объект
ModelAndView. - Префикс, суффикс и путь к шаблонам настраиваются в конфигурации
ViewResolver.
Ответ 18+ 🔞
А, ну вот, смотри, классика жанра, блядь! Весь этот цирк с конями в Spring MVC, где контроллер, как попугай, выкрикивает строчку, а потом прибегает этот ёбаный ViewResolver и начинает судорожно искать, какую же JSP или Thymeleaf-хуйню ему подсовывать.
Вот как это, сука, по косточкам разбирается, чтобы даже мартышка поняла:
- Запрос прилетает. Тыкнули в браузере какую-нибудь хуйню типа
/greet. Запрос, как пуля, — прямиком в метод контроллера, который помечен@GetMapping. Контроллер, блядь, просыпается. - Контроллер работает. Он там поковырялся в параметрах, потыкал палкой в сервисный слой (где вся бизнес-логика, которая обычно написана так, что волосы дыбом), и наковырянные результаты суёт в объект
Model. Как в мешок Санта-Клауса, епта. - Контроллер выдаёт результат. И выдаёт он не JSON и не XML, а просто строку, блядь! Какую-нибудь
"greetPage". И делает довольную рожу, типа «я всё». - Врывается
ViewResolver. А этот товарищ — настоящий детектив, ёпта. Он хватает эту строчку"greetPage", лезет в свои настройки, видит там что-то вроде «префикс = /WEB-INF/views/, суффикс = .html» и охуевает от счастья! Собирает пазл:/WEB-INF/views/+greetPage+.html. Всё, нашёл файлик! - Финальный акт. Движок шаблонов (Thymeleaf, JSP — неважно) берёт этот HTML-шаблон, выковыривает из
Modelвсе атрибуты (ту самую"message"с"Hello, Spring!") и впендюривает их на место. Получается готовый HTML, который и летит обратно в браузер. Красота, блядь!
Вот тебе живой пример, чтобы вообще ни хуя не осталось непонятного:
@Controller
public class GreetingController {
@GetMapping("/greet")
public String showGreeting(Model model) {
// Пихаем в модель сообщение. Это как записка в карман.
model.addAttribute("message", "Hello, Spring MVC!");
// А вот и магическая строчка! ViewResolver её потом расшифрует.
return "greetPage";
}
}На что тут, сука, внимание обратить, чтобы не облажаться:
- Если тебе надо не HTML, а чисто JSON для API — ты не
@Controllerиспользуй, а@RestController. Это такая волшебная комбинация, которая говорит: «чувак, не парься с шаблонами, просто верни объект, я его сам в JSON заверну».@Controller+@ResponseBody=@RestController. Запомни, идиот, и не путай! - Можно, конечно, и по-старинке — вернуть сразу целый объект
ModelAndView, туда и модель, и имя вьюхи запихнуть. Но это уже для мазохистов или любителей олдскула. - А вся эта магия с путями (
/WEB-INF/views/) настраивается в конфигурации того самогоViewResolver. Хочешь шаблоны из папки/templates/— пожалуйста. Хочешь расширение.jspвместо.html— да хуй с ним, настрой. Главное — не обосраться с путями, а то будет искать, искать, и охуевать.