Spis treści | Spring w Akcji
- Praca z Kontrolerami
Praca z Kontrolerami
Do tej pory napisałeś trzy kontrolery dla aplikacji Taco Cloud. Chociaż każdy kontroler służy odrębnemu celowi w funkcjonalności aplikacji, wszystkie one dość mocno trzymają się tego samego modelu programowania:
- Wszystkie są opatrzone adnotacją @Controller, aby wskazać, że są to klasy kontrolerów, które powinny być automatycznie odkryte przez skanowanie komponentów Spring i zainicjowane jako bean w kontekście aplikacji Spring.
- Wszystkie oprócz HomeController posiadają adnotację @RequestMapping na poziomie klasy, aby zdefiniować podstawowy wzorzec żądań, które kontroler będzie obsługiwał.
- Wszystkie mają jedną lub więcej metod, które mają adnotacje @GetMapping lub @PostMapping, aby zapewnić specyfikę, które metody powinny obsługiwać poszczególne rodzaje żądań.
Większość kontrolerów, które napiszesz, będzie podążać za tym wzorcem. Jednak gdy kontroler jest na tyle prosty, że nie wypełnia modelu ani nie przetwarza danych wejściowych – jak w przypadku kontrolera HomeController – istnieje inny sposób, w jaki można go zdefiniować. Spójrz na następny listing, aby zobaczyć jak możesz zadeklarować kontroler widoku – kontroler, który nie robi nic poza przekazaniem żądania do widoku.
Najbardziej znaczącą rzeczą, którą należy zauważyć w @WebConfig jest to, że implementuje on interfejs Web- MvcConfigurer. WebMvcConfigurer definiuje kilka metod konfigurowania Spring MVC. Pomimo tego, że jest to interfejs, zapewnia on domyślne implementacje wszystkich
metod, więc musisz nadpisać tylko te metody, których potrzebujesz. W tym przypadku nadpisujesz metodę addViewControllers().
Metoda addViewControllers() otrzymuje ViewControllerRegistry, którego możesz użyć do zarejestrowania jednego lub więcej kontrolerów widoku. Tutaj wywołujesz addViewController() na rejestrze, przekazując „/”, czyli ścieżkę, dla której twój kontroler widoku będzie obsługiwał żądania GET. Metoda ta zwraca obiekt ViewControllerRegistration, na którym natychmiast wywołujesz setViewName(), aby określić home jako widok, do którego powinno być przekazane żądanie dla „/”.
I tak po prostu, byłeś w stanie zastąpić HomeController kilkoma liniami w klasie konfiguracyjnej. Możesz teraz usunąć HomeController, a aplikacja nadal powinna zachowywać się tak, jak wcześniej. Jedyną inną wymaganą zmianą jest ponowne przeanalizowanie Home- ControllerTest z rozdziału 1, usuwając odwołanie do HomeController z adnotacji @WebMvcTest, tak aby klasa testowa skompilowała się bez błędów.
Stworzyłeś tutaj nową klasę konfiguracyjną WebConfig, aby pomieścić deklarację kon-trolera widoku. Ale każda klasa konfiguracyjna może implementować WebMvcConfigurer i nadpisać metodę addViewController. Na przykład mogłeś dodać tę samą deklarację kontrolera widoku do klasy bootstrapowej TacoCloudApplication w ten sposób:
Rozszerzając istniejącą klasę konfiguracyjną, można uniknąć tworzenia nowej klasy konfiguracyjnej, co pozwala zmniejszyć liczbę artefaktów projektu. Ja jednak wolę tworzyć nową klasę konfiguracyjną dla każdego rodzaju konfiguracji (WWW, dane, bezpieczeństwo i tak dalej), utrzymując konfigurację startową aplikacji w czystości i prostocie.
Mówiąc o kontrolerach widoku, a ogólniej o widokach, do których kontrolery kierują żądania, do tej pory używałeś Thymeleaf dla wszystkich swoich widoków. Ja bardzo lubię Thymeleaf, ale może wolisz inny model szablonu dla widoków swojej aplikacji. Przyjrzyjmy się wielu obsługiwanym przez Spring opcjom widoków.
Pomocne linki