streamalism.org

1. Úvod

Spring MVC je pôvodný webový rámec z Springu postavený na Servlet API. Poskytuje architektúru Model-View-Controller, ktorú je možné použiť na vývoj flexibilných webových aplikácií.

V tomto tutoriáli sa zameriame na otázky, ktoré sa ho týkajú, pretože je často témou jarného pracovného pohovoru pre vývojárov.

Ak sa chcete dozvedieť viac otázok o jarnom rámci, môžete si prečítať ďalší článok z našej série otázok o rozhovoroch týkajúcich sa jari.

2. Základné jarné otázky MVC

Q1. Prečo by sme mali používať jarné MVC?

Spring MVC implementuje jasné oddelenie záujmov, čo nám umožňuje ľahko vyvíjať a testovať naše aplikácie.

Pojmy ako:

• Servlet dispečera
• Kontrolóri
• Zobraziť riešenie
• Pohľady, Modely
• ModelAndView
• Atribúty modelu a relácie

sú na sebe úplne nezávislé a sú zodpovední iba za jednu vec.

Preto MVC nám dáva dosť veľkú flexibilitu. Je založený na rozhraniach (s poskytnutými implementačnými triedami) a pomocou vlastných rozhraní môžeme nakonfigurovať každú časť rámca.

Ďalšou dôležitou vecou je, že nie sme viazaní na konkrétnu technológiu zobrazenia (napríklad JSP), ale máme možnosť vybrať si z tých, ktoré sa nám páčia najviac.

Tiež jarné MVC nepoužívame iba pri vývoji webových aplikácií, ale aj pri tvorbe webových služieb RESTful.

Q2. Aká je úloha agentúry @Autowired Anotácia?

The @Autowired anotáciu je možné použiť pri poliach alebo metódach na injekciu fazule podľa typu. Táto anotácia umožňuje spoločnosti Spring vyriešiť a vstreknúť spolupracujúce fazule do vašej fazule.

Viac podrobností nájdete v príručke o @Autowired na jar.

Q3. Vysvetlite atribút modelu

The @ModelAttribute anotácia je jednou z najdôležitejších anotácií v jarnom MVC. Viaže parameter metódy alebo návratovú hodnotu metódy na atribút pomenovaného modelu a potom ho vystavuje webovému zobrazeniu.

Ak ho použijeme na úrovni metódy, znamená to, že účelom tejto metódy je pridať jeden alebo viac atribútov modelu.

Na druhej strane, ak sa použije ako argument metódy, znamená to, že argument sa má načítať z modelu. Ak nie je prítomný, mali by sme ho najskôr vytvoriť inštanciu a potom ho pridať do modelu. Len čo sú v modeli, mali by sme vyplniť polia argumentov zo všetkých parametrov požiadavky, ktoré majú zodpovedajúce názvy.

Viac o tejto anotácii nájdete v našom článku týkajúceho sa @ModelAttribute anotácia.

Q4. Vysvetlite rozdiel @ Kontrolór a @RestController?

Hlavný rozdiel medzi @ Kontrolór a @RestController anotácií je to the @ResponseBody poznámka je automaticky zahrnutá do @RestController. To znamená, že nemusíme anotovať naše metódy obsluhy pomocou @ResponseBody. Musíme to urobiť v a @ Kontrolór triedy, ak chceme zapísať typ odpovede priamo do tela odpovede HTTP.

Q5. Popíšte a PathVariable

Môžeme použiť @PathVariable anotácia ako parameter metódy obslužnej rutiny s cieľom extrahovať hodnotu premennej šablóny URI.

Napríklad, ak chceme načítať používateľa pomocou id z www.mysite.com/user/123, mali by sme našu metódu namapovať do ovládača ako /ID používateľa}:

@RequestMapping ("/ user / {id}") verejný reťazec handleRequest (@PathVariable ("id") reťazec userId, modelová mapa) {}

The @PathVariable má iba jeden pomenovaný prvok hodnotu. Je to voliteľné a používame ho na definovanie názvu premennej šablóny URI. Ak vynecháme hodnotový prvok, potom sa názov premennej šablóny URI musí zhodovať s názvom parametra metódy.

Je tiež povolené mať viac @PathVariable anotácií, a to buď ich vyhlásením jeden po druhom:

@RequestMapping ("/ user / {userId} / name / {userName}") public String handleRequest (@PathVariable String userId, @PathVariable String userName, Model map) {}

alebo ich všetky umiestniť do a Mapa alebo MultiValueMap:

@RequestMapping ("/ user / {userId} / name / {userName}") verejný reťazec handleRequest (@PathVariable Map varsMap, modelová mapa) {}

Q6. Validácia pomocou Spring MVC

Spring MVC štandardne podporuje špecifikácie JSR-303. Musíme pridať JSR-303 a jeho implementačné závislosti do našej aplikácie Spring MVC. Napríklad Hibernate Validator je jednou z implementácií JSR-303, ktoré máme k dispozícii.

JSR-303 je špecifikácia Java API pre validáciu fazule, súčasť programov Jakarta EE a JavaSE, ktorá zaisťuje, aby vlastnosti fazule spĺňali špecifické kritériá, a to pomocou anotácií ako napr. @NotNull, @ Mina @ Max. Viac informácií o overovaní je k dispozícii v článku Základy overenia Java Bean.

Jar ponúka @ Validator anotácia a BindingResult trieda. The Validátor implementácia spôsobí chyby v metóde obsluhy žiadosti o kontrolór, keď máme neplatné údaje. Potom môžeme použiť BindingResult triedy na získanie týchto chýb.

Okrem použitia existujúcich implementácií si môžeme vyrobiť aj vlastné. Za týmto účelom najskôr vytvoríme anotáciu, ktorá je v súlade so špecifikáciami JSR-303. Potom implementujeme Validátor trieda. Ďalším spôsobom by bola implementácia Spring's Validátor rozhranie a nastaviť ho ako validátor cez @InitBinder anotácia v Kontrolór trieda.

Ak sa chcete dozvedieť, ako implementovať a používať svoje vlastné validácie, prečítajte si návod týkajúci sa vlastnej validácie na jar MVC.

Q7. Čo sú @RequestBody a @ResponseBody?

The @RequestBody anotácia, ktorá sa používa ako parameter metódy obslužnej rutiny, viaže telo požiadavky HTTP na prenos alebo doménový objekt. Jar automaticky deserializuje prichádzajúce HTTP požiadavky na objekt Java pomocou prevádzačov správ HTTP.

Keď použijeme @ResponseBody anotácia k metóde obsluhy v ovládači Spring MVC, znamená to, že návratový typ metódy napíšeme priamo do tela odpovede HTTP. Nebudeme to dávať do a Modela Spring nebude interpretovať ako názov zobrazenia.

Prečítajte si článok o @RequestBody a @ResponseBody Ak chcete zobraziť viac podrobností o týchto anotáciách.

Q8. Vysvetlite Model, ModelMap a ModelAndView?

The Model rozhranie definuje držiteľa atribútov modelu. The ModelMap má podobný účel, so schopnosťou odovzdať zbierku hodnôt. S týmito hodnotami potom zaobchádza, akoby boli v rámci a Mapa. Mali by sme poznamenať, že v Model (ModelMap) môžeme ukladať iba údaje. Vložíme údaje a vrátime názov zobrazenia.

Na druhej strane, s ModelAndView, vrátime samotný objekt. V objekte, ktorý vraciame, sme nastavili všetky požadované informácie, ako sú údaje a názov zobrazenia.

Viac podrobností nájdete v článku na Model, ModelMapa ModelView.

Q9. Vysvetlite Atribúty relácie a SessionAttribute

The @SessionAttributes anotácia sa používa na uloženie atribútu modelu v relácii používateľa. Používame ho na úrovni triedy radiča, ako je uvedené v našom článku o atribútoch relácie na jar MVC:

@Controller @RequestMapping ("/ sessionattributes") @SessionAttributes ("todos") verejná trieda TodoControllerWithSessionAttributes {@GetMapping ("/ form") public String showForm (model model, @ModelAttribute ("todos") TodoList todos) {// metóda návrat tela "sessionattributesform"; } // ďalšie metódy}

V predchádzajúcom príklade atribút modelu ‘todos„Bude pridaný k relácii, ak @ModelAttribute a @SessionAttributes majú rovnaký atribút názvu.

Ak chceme získať existujúci atribút z relácie, ktorá je spravovaná globálne, použijeme @SessionAttribute anotácia ako parameter metódy:

@GetMapping public String getTodos (@SessionAttribute ("todos") TodoList todos) {// telo metódy return "todoView"; }

Q10. Aký je účel @EnableWebMVC?

The @EnableWebMvc účelom anotácie je povoliť Spring MVC cez konfiguráciu Java. Je to ekvivalent k v konfigurácii XML. Táto anotácia importuje konfiguráciu Spring MVC z WebMvcConfigurationSupport. Umožňuje podporu pre @ Kontrolór- anotované triedy, ktoré používajú @RequestMapping na mapovanie prichádzajúcich požiadaviek na metódu obsluhy.

Viac o tejto a podobných anotáciách sa dozviete v našom Sprievodcovi jarou @Povoliť Anotácie.

Q11. Čo je ViewResolver na jar?

The ViewResolver umožňuje aplikácii vykresľovať modely v prehľadávači - bez viazania implementácie na konkrétnu technológiu zobrazenia - mapovaním názvov pohľadov na skutočné pohľady.

Pre viac informácií o ViewResolver, pozrite si nášho Sprievodcu po ViewResolver na jar MVC.

Q12. Čo je BindingResult?

BindingResult je rozhranie z org.springframework.validation balíček, ktorý predstavuje záväzné výsledky. Môžeme ho použiť na zisťovanie a hlásenie chýb v odoslanom formulári. Je ľahké sa na ňu odvolať - stačí sa ubezpečiť, že sme ju vložili ako parameter hneď za objekt formulára, ktorý overujeme. Nepovinné Model parameter by mal nasledovať po BindingResult, ako je možné vidieť v tutoriáli vlastného validátora:

@PostMapping ("/ user") public String submitForm (@Valid NewUserForm newUserForm, BindingResult result, Model model) {if (result.hasErrors ()) {return "userHome"; } model.addAttribute ("správa", "platný formulár"); vrátiť "userHome"; }

Keď jar uvidí @ Platné anotácie, najskôr sa pokúsi nájsť validátor pre objekt, ktorý sa overuje. Potom prevezme anotácie overenia a vyvolá validátor. Na záver vloží nájdené chyby do súboru BindingResult a pridať druhú do modelu zobrazenia.

Q13. Čo je to objekt podporujúci formulár?

Objekt podporujúci formulár alebo príkazový objekt je iba POJO, ktorý zhromažďuje údaje z formulára, ktorý odosielame.

Mali by sme mať na pamäti, že neobsahuje žiadnu logiku, iba údaje.

Ak sa chcete dozvedieť, ako používať podporný objekt formulára s formulármi v jarnom MVC, prečítajte si náš článok o formulároch v jarnom MVC.

Q14. Aká je úloha agentúry @Qualifier Anotácia?

Používa sa súčasne s @Autowired anotácia, aby nedošlo k zámene, keď je prítomných viac inštancií typu fazuľa.

Pozrime sa na príklad. V konfigurácii XML sme deklarovali dve podobné fazule:

Keď sa pokúsime fazuľu zdrôtovať, dostaneme org.springframework.beans.factory.NoSuchBeanDefinitionException. Aby sme to napravili, musíme použiť @Qualifier povedať jari o tom, ktorá fazuľa by mala byť zapojená:

@Autowired @Qualifier ("person1") súkromná osoba;

Q15. Aká je úloha agentúry @Požadovaný Anotácia?

The @Požadovaný anotácia sa používa na metódach nastavovača a naznačuje, že vlastnosť fazule, ktorá má túto anotáciu, musí byť vyplnená v čase konfigurácie. V opačnom prípade nádoba Spring hodí a BeanInitializationException výnimkou.

Tiež @Požadovaný sa líši od @Autowired - keďže sa obmedzuje na pôvodcu, zatiaľ čo @Autowired nie je. @Autowired možno použiť na drôtovanie s konštruktorom a poľom tiež, zatiaľ čo @Požadovaný skontroluje iba to, či je vlastnosť nastavená.

Pozrime sa na príklad:

public class Osoba {private String name; @ Požadovaná verejná neplatnosť setName (názov reťazca) {this.name = meno; }}

Teraz názov z Osoba bean je potrebné nastaviť v konfigurácii XML takto:

Vezmite prosím na vedomie, že @Požadovaný nefunguje na báze Java @ Konfigurácia triedy štandardne. Ak sa potrebujete ubezpečiť, že sú nastavené všetky vaše vlastnosti, môžete tak urobiť pri vytváraní fazule v @Bean anotované metódy.

Q16. Popíšte vzor predného ovládača

Vo vzore predného radiča budú všetky požiadavky najskôr smerované do predného radiča namiesto servletu. Zaistí, že sú odpovede pripravené, a odošle ich späť do prehliadača. Takto máme jedno miesto, kde ovládame všetko, čo pochádza z vonkajšieho sveta.

Predný radič identifikuje servlet, ktorý by mal vybaviť požiadavku ako prvý. Potom, keď získa údaje späť z servletu, rozhodne, ktoré zobrazenie sa má vykresliť, a nakoniec odošle vykreslené zobrazenie späť ako odpoveď:

Podrobnosti o implementácii nájdete v našom Sprievodcovi vzorom predného ovládača v jazyku Java.

Q17. Čo sú architektúry modelu 1 a modelu 2?

Model 1 a Model 2 predstavujú dva často používané dizajnové modely, pokiaľ ide o návrh webových aplikácií Java.

V modeli 1 prichádza požiadavka na servlet alebo JSP, kde sa vybavia. Servlet alebo JSP spracuje požiadavku, spracuje obchodnú logiku, načíta a overí údaje a vygeneruje odpoveď:

Pretože sa táto architektúra ľahko implementuje, zvyčajne ju používame v malých a jednoduchých aplikáciách.

Na druhej strane to nie je vhodné pre rozsiahle webové aplikácie. Funkcie sú často duplikované v JSP, kde je spojená obchodná a prezentačná logika.

Model 2 je založený na návrhovom vzore radiča zobrazenia modelu a oddeľuje pohľad od logiky, ktorá manipuluje s obsahom.

Ďalej môžeme vo vzore MVC rozlišovať tri moduly: model, pohľad a radič. Model predstavuje dynamickú dátovú štruktúru aplikácie. Zodpovedá za manipuláciu s dátami a obchodnou logikou. Zobrazenie má na starosti zobrazenie údajov, zatiaľ čo ovládač slúži ako rozhranie medzi predchádzajúcimi dvoma.

V modeli 2 sa požiadavka odovzdá radiču, ktorý spracováva požadovanú logiku, aby získal správny obsah, ktorý by sa mal zobraziť. Ovládač potom vloží obsah späť do požiadavky, zvyčajne ako JavaBean alebo POJO. Rozhoduje tiež o tom, ktoré zobrazenie by malo obsah vykresliť, a nakoniec mu odovzdá žiadosť. Pohľad potom vykreslí údaje:

3. Pokročilé jarné otázky MVC

Q18. Aký je rozdiel @ Kontrolór, @ Komponent, @Úložisko, a @Služba Anotácie na jar?

Podľa oficiálnej jarnej dokumentácie @ Komponent je všeobecný stereotyp pre ktorýkoľvek komponent spravovaný Springom. @Úložisko, @Službaa @ Kontrolór sú špecializácie @ Komponent pre konkrétnejšie prípady použitia, napríklad vo vrstvách perzistencie, služby a prezentácie.

Pozrime sa na konkrétne prípady použitia posledných troch:

• @Kontrolór - označuje, že trieda slúži ako kontrolór a detekuje @RequestMapping anotácie v rámci triedy
• @Služby - označuje, že trieda obsahuje obchodnú logiku a volá metódy vo vrstve úložiska
• @Úložisko - označuje, že trieda definuje úložisko údajov; jeho úlohou je zachytiť výnimky špecifické pre platformu a znova ich vyhodiť ako jednu zo zjednotených nekontrolovaných výnimiek spoločnosti Spring

Q19. Čo sú DispatcherServlet a ContextLoaderListener?

Jednoducho povedané, v dizajnovom vzore predného ovládača je za smerovanie prichádzajúcich zodpovedný jeden radič HttpRequests všetkým ďalším radičom a obslužným programom aplikácie.

Spring’s DispatcherServlet implementuje tento model a je preto zodpovedný za správnu koordináciu HttpRequests správnym manipulátorom.

Na druhej strane, ContextLoaderListener naštartuje a vypne jarný koreň WebApplicationContext. Viaže životný cyklus ApplicationContext do životného cyklu ServletContext. Môžeme ho použiť na definovanie zdieľaných bôbov pracujúcich v rôznych jarných kontextoch.

Pre viac informácií o DispatcherServlet, pozrite si prosím tento návod.

Q20. Čo je a MultipartResolver a kedy by sme to mali použiť?

The MultipartResolver rozhranie sa používa na nahrávanie súborov. Jarný rámec jednu poskytuje MultipartResolver implementácia na použitie s Commons FileUpload a ďalšia na použitie s analýzou viacdielnych požiadaviek na Servlet 3.0.

Pomocou nich môžeme podporovať nahrávanie súborov v našich webových aplikáciách.

Q21. Čo je Spring MVC Interceptor a ako ho používať?

Jarné zachytávače MVC nám umožňujú zachytiť požiadavku klienta a spracovať ju na troch miestach - pred vybavením, po spracovaní alebo po dokončení (pri vykreslení zobrazenia) žiadosti.

Zachytávač je možné použiť na prierezové problémy a na zabránenie opakovaniu kódu obslužného programu, ako je napríklad prihlásenie, zmena globálne používaných parametrov v modeli Spring atď.

Podrobnosti a rôzne implementácie nájdete v článku Úvod do jarnej verzie MVC HandlerInterceptor.

Q22. Čo je to Init Binder?

Metóda s poznámkou @InitBinder sa používa na prispôsobenie parametra požiadavky, šablóny URI a podporných / príkazových objektov. Definujeme to v radiči a pomáha nám to pri kontrole požiadavky. V tejto metóde zaregistrujeme a nakonfigurujeme náš zvyk PropertyEditors, formátovač a validátory.

Anotácia má „hodnotu' element. Ak ju nenastavíme, @InitBinder pri každej požiadavke HTTP sa budú volať anotované metódy. Ak nastavíme hodnotu, metódy sa použijú iba pre konkrétne atribúty príkazu / formulára a / alebo parametre požiadavky, ktorých názvy zodpovedajú ‘hodnotu' element.

Je dôležité mať na pamäti, že jedným z argumentov musí byť WebDataBinder. Ďalšie argumenty môžu byť ľubovoľného typu, ktoré metódy obslužných rutín podporujú, okrem objektov príkazov / formulárov a zodpovedajúcich objektov s výsledkami overenia.

Q23. Vysvetlite radu pre radiča

The @ControllerAdvice anotácia nám umožňuje písať globálny kód použiteľný pre širokú škálu radičov. Rozsah radičov môžeme viazať na vybrané balenie alebo konkrétnu anotáciu.

Predvolene, @ControllerAdvice platí pre triedy s poznámkami @ Kontrolór (alebo @RestController). Máme tiež niekoľko vlastností, ktoré používame, ak chceme byť konkrétnejší.

Ak chceme obmedziť príslušné triedy na balík, mali by sme do anotácie pridať názov balíka:

@ControllerAdvice ("my.package") @ControllerAdvice (value = "my.package") @ControllerAdvice (basePackages = "my.package")

Je tiež možné použiť viac balíkov, ale tentokrát musíme namiesto poľa použiť pole String.

Okrem obmedzenia na názov balíka to môžeme urobiť použitím jednej z tried alebo rozhraní z tohto balíka:

@ControllerAdvice (basePackageClasses = MyClass.class)

„assignableTypes„Prvok uplatňuje @ControllerAdvice do konkrétnych tried, zatiaľ čo „anotácie„Robí to pre konkrétne anotácie.

Je potrebné pripomenúť, že by sme ho mali používať spolu s @ExceptionHandler. Táto kombinácia nám umožní nakonfigurovať globálny a konkrétnejší mechanizmus spracovania chýb bez nutnosti zakaždým ho implementovať pre každú triedu radičov.

Q24. Čo robí @ExceptionHandler Anotácia?

The @ExceptionHandler anotácia nám umožňuje definovať metódu, ktorá bude spracovávať výnimky. Anotáciu môžeme použiť nezávisle, ale je to oveľa lepšia možnosť, ako ju použiť spolu s @ControllerAdvice. Môžeme teda nastaviť globálny mechanizmus riešenia chýb. Týmto spôsobom nemusíme písať kód na spracovanie výnimiek v rámci každého radiča.

Pozrime sa na príklad z nášho článku o spracovaní chýb pre REST s pružinou:

@ControllerAdvice verejná trieda RestResponseEntityExceptionHandler rozširuje ResponseEntityExceptionHandler {@ExceptionHandler (value = {IllegalArgumentException.class, IllegalStateException.class}) chránený ResponseEntity handleConflict (RuntimeException ex, požiadavka WebRequest) return handleExceptionInternal (ex, bodyOfResponse, new HttpHeaders (), HttpStatus.CONFLICT, request); }}

Mali by sme tiež poznamenať, že to poskytne @ExceptionHandler metódy pre všetky ovládače, ktoré vrhajú IllegalArgumentException alebo IllegalStateException. Výnimky deklarované s @ExceptionHandler by sa mala zhodovať s výnimkou použitou ako argument metódy. V opačnom prípade mechanizmus riešenia výnimiek za behu zlyhá.

Tu treba mať na pamäti jednu vec, že ​​je možné definovať viac ako jednu @ExceptionHandler pre tú istú výnimku. Nemôžeme to urobiť v tej istej triede, pretože Spring by si sťažoval, že udelí výnimku a zlyhá pri štarte.

Na druhej strane, ak ich definujeme v dvoch samostatných triedach, aplikácia sa spustí, ale použije prvý nájdený obslužný program, možno nesprávny.

Q25. Spracovanie výnimiek vo webových aplikáciách

V Spring MVC máme tri možnosti riešenia výnimiek:

• na výnimku
• na kontrolóra
• globálne

Ak sa počas spracovania webovej požiadavky vyvolá nespracovaná výnimka, server vráti odpoveď HTTP 500. Aby ste tomu zabránili, mali by sme anotovať každú z našich vlastných výnimiek pomocou @ResponseStatus anotácia. Tento druh výnimiek je vyriešený HandlerExceptionResolver.

Toto spôsobí, že server vráti príslušnú odpoveď HTTP so zadaným stavovým kódom, keď metóda kontrolóra vyvolá našu výnimku. Mali by sme mať na pamäti, že by sme nemali riešiť našu výnimku niekde inde pre tento prístup k práci.

Ďalším spôsobom, ako zvládnuť výnimky, je použitie súboru @ExceptionHandler anotácia. Pridáme @ExceptionHandler metódy ľubovoľnému radiču a použiť ich na spracovanie výnimiek vyvolaných zvnútra tohto radiča. Tieto metódy dokážu zvládnuť výnimky bez znaku @ResponseStatus anotácie, presmerujte používateľa na vyhradené zobrazenie chýb alebo vytvorte úplne vlastnú reakciu na chyby.

Môžeme tiež odovzdať objekty súvisiace so servletom (HttpServletRequest, HttpServletResponse, HttpSessiona Principal) ako parametre metód obsluhy. Mali by sme však pamätať na to, že nemôžeme dať Model objekt ako parameter priamo.

Tretia možnosť riešenia chýb je v @ControllerAdvice triedy. Umožní nám to aplikovať rovnaké techniky, tentokrát však iba na aplikačnej úrovni, nielen na konkrétny radič. Aby sme to umožnili, musíme použiť @ControllerAdvice a @ExceptionHandler spolu. Týmto spôsobom budú obslužné rutiny výnimiek spracovávať výnimky vyvolané ktorýmkoľvek radičom.

Podrobnejšie informácie o tejto téme nájdete v článku Riešenie chýb pre REST s jarou.

4. Záver

V tomto článku sme sa venovali niektorým otázkam súvisiacim s jarným MVC, ktoré by mohli vyjsť pri technickom rozhovore pre vývojárov jari. Tieto otázky by ste mali brať do úvahy ako východiskový bod pre ďalší výskum, pretože to v žiadnom prípade nie je vyčerpávajúci zoznam.

Prajeme vám veľa šťastia v budúcich rozhovoroch!