streamalism.org

1. Introduksjon

Spring MVC er det opprinnelige nettrammeverket fra Spring bygget på Servlet API. Det gir Model-View-Controller-arkitektur som kan brukes til å utvikle fleksible webapplikasjoner.

I denne opplæringen vil vi fokusere på spørsmålene knyttet til det, da det ofte er et tema på et jobbintervju om våren.

For flere spørsmål om Spring Framework, kan du sjekke ut en annen vårrelatert artikkel i vår intervjuspørsmålsserie.

2. Grunnleggende MVC-spørsmål om våren

Q1. Hvorfor skal vi bruke våren MVC?

Spring MVC implementerer en klar separasjon av bekymringer som lar oss utvikle og enhetstest applikasjonene våre enkelt.

Konseptene som:

• Dispatcher Servlet
• Kontrollere
• Vis Resolvers
• Visninger, modeller
• ModelAndView
• Modell- og sesjonsattributter

er helt uavhengige av hverandre, og de er bare ansvarlige for en ting.

Derfor, MVC gir oss ganske stor fleksibilitet. Den er basert på grensesnitt (med medfølgende implementeringsklasser), og vi kan konfigurere alle deler av rammeverket ved å bruke tilpassede grensesnitt.

En annen viktig ting er at vi ikke er bundet til en bestemt visningsteknologi (for eksempel JSP), men vi har muligheten til å velge blant de vi liker best.

Også, vi bruker ikke Spring MVC bare i utvikling av webapplikasjoner, men også i etableringen av RESTful web-tjenester.

Q2. Hva er rollen til @Autowired Kommentar?

De @Autowired merknader kan brukes med felt eller metoder for å injisere en bønne etter type. Denne merknaden lar våren løse og injisere bønner som samarbeider.

For mer informasjon, se opplæringen om @Autowired på våren.

Q3. Forklar et modellattributt

De @ModelAttribute kommentar er en av de viktigste kommentarene i Spring MVC. Det binder en metodeparameter eller en metodeverdiverdi til et navngitt modellattributt og eksponerer det deretter for en webvisning.

Hvis vi bruker det på metodenivå, indikerer det at formålet med denne metoden er å legge til en eller flere modellattributter.

På den annen side, når det brukes som et metodargument, indikerer det at argumentet skal hentes fra modellen. Når den ikke er tilstede, bør vi først instantiere den og deretter legge den til modellen. Når vi er til stede i modellen, bør vi fylle ut argumentfeltene fra alle forespørselsparametere som har samsvarende navn.

Mer om denne merknaden finner du i vår artikkel relatert til @ModelAttribute kommentar.

Q4. Forklar forskjellen mellom @Kontrollør og @RestController?

Hovedforskjellen mellom @Kontrollør og @RestController merknader er det de @ResponseBody merknader er automatisk inkludert i @RestController. Dette betyr at vi ikke trenger å kommentere håndteringsmetodene våre med @ResponseBody. Vi må gjøre dette i en @Kontrollør klasse hvis vi ønsker å skrive responstype direkte til HTTP-responsorganet.

Q5. Beskriv a PathVariable

Vi kan bruke @PathVariable merknad som parameter for håndterermetode for å trekke ut verdien til en URI-malvariabel.

For eksempel hvis vi ønsker å hente en bruker etter ID fra www.mysite.com/user/123, bør vi kartlegge metoden vår i kontrolleren som /bruker-ID}:

@RequestMapping ("/ user / {id}") offentlig streng handleRequest (@PathVariable ("id") Streng userId, modellkart) {}

De @PathVariable har bare ett element som heter verdi. Det er valgfritt, og vi bruker det til å definere navnet på URI-malvariabelen. Hvis vi utelater verdielementet, må navnet på URI-malvariabelen samsvare med metoden parameternavn.

Det er også lov å ha flere @PathVariable kommentarer, enten ved å erklære dem etter hverandre:

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

eller sette dem alle i en Kart eller MultiValueMap:

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

Q6. Validering ved bruk av vår-MVC

Spring MVC støtter JSR-303 spesifikasjoner som standard. Vi må legge til JSR-303 og dens implementeringsavhengigheter i vår MVC-applikasjon. Hibernate Validator, for eksempel, er en av JSR-303-implementeringene vi har tilgjengelig.

JSR-303 er en spesifikasjon av Java API for validering av bønner, en del av Jakarta EE og JavaSE, som sørger for at egenskapene til en bønne oppfyller spesifikke kriterier, ved å bruke merknader som @Ikke null, @Min, og @Max. Mer om validering er tilgjengelig i Java Bean Validation Basics-artikkelen.

Våren tilbyr @Validator kommentar og Bindende resultat klasse. De Validator implementering vil føre til feil i behandlingsmetoden for kontrollerforespørsel når vi har ugyldige data. Da kan vi bruke Bindende resultat klasse for å få disse feilene.

Foruten å bruke eksisterende implementeringer, kan vi lage våre egne. For å gjøre det oppretter vi en kommentar som samsvarer med JSR-303-spesifikasjonene først. Deretter implementerer vi Validator klasse. En annen måte ville være å implementere vårens Validator grensesnitt og angi det som validator via @InitBinder kommentar i Kontroller klasse.

For å sjekke ut hvordan du implementerer og bruker dine egne valideringer, se veiledningen angående tilpasset validering i Spring MVC.

Q7. Hva er @Fotball og @ResponseBody?

De @RequestBody merknad, brukt som parameter for håndterermetode, binder HTTP-forespørsel-kroppen til en overføring eller et domeneobjekt. Spring deserialiserer automatisk innkommende HTTP-forespørsel til Java-objektet ved hjelp av Http Message Converters.

Når vi bruker @ResponseBody merknad om en behandlingsmetode i Spring MVC-kontrolleren, det indikerer at vi skriver returtypen til metoden direkte til HTTP-responsorganet. Vi legger det ikke i en Modell, og Spring vil ikke tolke som et visningsnavn.

Vennligst sjekk artikkelen på @Fotball og @ResponseBody for å se mer informasjon om disse kommentarene.

Q8. Forklare Modell, ModelMap og ModelAndView?

De Modell grensesnitt definerer en holder for modellattributter. De ModelMap har et lignende formål, med evnen til å formidle en samling verdier. Den behandler deretter disse verdiene som om de var innenfor et Kart. Vi bør merke oss at i Modell (ModelMap) vi kan bare lagre data. Vi legger inn data og returnerer et visningsnavn.

På den andre siden, med ModelAndView, returnerer vi selve gjenstanden. Vi setter all nødvendig informasjon, som dataene og visningsnavnet, i objektet vi returnerer.

Du finner mer detaljer i artikkelen på Model, ModelMap, og ModelView.

Q9. Forklare SessionAttributter og SessionAttribute

De @SessionAttributes merknader brukes til å lagre modellattributtet i brukerens økt. Vi bruker den på kontrollernivånivå, som vist i artikkelen vår om sesjonsattributtene i vår MVC:

@Controller @RequestMapping ("/ sessionattributes") @SessionAttributes ("todos") public class TodoControllerWithSessionAttributes {@GetMapping ("/ form") public String showForm (Model model, @ModelAttribute ("todos") TodoList todos) {// method kroppsretur "sessionattributesform"; } // andre metoder}

I forrige eksempel er modellattributtet ‘todos'Vil bli lagt til økten hvis @ModelAttribute og @SessionAttributes har samme navnattributt.

Hvis vi vil hente det eksisterende attributtet fra en økt som administreres globalt, bruker vi @SessionAttribute kommentar som metodeparameter:

@GetMapping offentlig streng getTodos (@SessionAttribute ("todos") TodoList todos) {// method body return "todoView"; }

Q10. Hva er formålet med @EnableWebMVC?

De @EnableWebMvc merknadens formål er å aktivere Spring MVC via Java-konfigurasjon. Det tilsvarer i en XML-konfigurasjon. Denne merknaden importerer Spring MVC Configuration fra WebMvcConfigurationSupport. Det muliggjør støtte for @Kontrollør-anmeldte klasser som bruker @RequestMapping for å kartlegge innkommende forespørsler til en behandlingsmetode.

Du kan lære mer om dette og lignende kommentarer i vår guide til våren @Muliggjøre Kommentarer.

Q11. Hva er ViewResolver på våren?

De ViewResolver gjør det mulig for et program å gjengi modeller i nettleseren - uten å knytte implementeringen til en bestemt visningsteknologi - ved å kartlegge visningsnavn til faktiske visninger.

For mer informasjon om ViewResolver, ta en titt på vår guide til ViewResolver i Spring MVC.

Q12. Hva er Bindende resultat?

Bindende resultat er et grensesnitt fra org.springframework.validation pakke som representerer bindende resultater. Vi kan bruke den til å oppdage og rapportere feil i det innsendte skjemaet. Det er lett å påkalle - vi må bare sørge for at vi setter det som en parameter rett etter skjemaobjektet vi validerer. Valgfritt Modell parameteren skal komme etter Bindende resultat, som det kan sees i den tilpassede validatorveiledningen:

@PostMapping ("/ user") public String submitForm (@Valid NewUserForm newUserForm, BindingResult result, Model model) {if (result.hasErrors ()) {return "userHome"; } model.addAttribute ("melding", "Gyldig skjema"); returner "userHome"; }

Når våren ser @Gyldig merknad, vil den først prøve å finne validatoren for objektet som valideres. Deretter henter valideringsnotatene og påkaller validatoren. Endelig vil det sette funnet feil i Bindende resultat og legg sistnevnte til visningsmodellen.

Q13. Hva er et formstøtteobjekt?

Formstøtteobjektet eller et kommandoobjekt er bare en POJO som samler inn data fra skjemaet vi sender inn.

Vi bør huske på at den ikke inneholder noen logikk, bare data.

For å lære hvordan du bruker skjemaunderlagsobjekt med skjemaene i Spring MVC, ta en titt på artikkelen vår om Forms in Spring MVC.

Q14. Hva er rollen til @Kvalifiserende Kommentar?

Den brukes samtidig med @Autowired kommentar for å unngå forvirring når flere forekomster av en bønnetype er til stede.

La oss se et eksempel. Vi erklærte to lignende bønner i XML-konfigurasjon:

Når vi prøver å koble bønnen, får vi en org.springframework.beans.factory.NoSuchBeanDefinitionException. For å fikse det, må vi bruke @Kvalifiserende å fortelle våren om hvilken bønne som skal kobles til:

@Autowired @Qualifier ("person1") privatperson person;

Q15. Hva er rollen til @Krevd Kommentar?

De @Krevd merknader brukes på settermetoder, og det indikerer at bønneegenskapen som har denne merknaden, må fylles ut på konfigurasjonstidspunktet. Ellers vil fjærbeholderen kaste et BeanInitializationException unntak.

Også, @Krevd skiller seg fra @Autowired - da det er begrenset til en setter, mens @Autowired er ikke. @Autowired kan brukes til å koble med en konstruktør og et felt også, mens @Krevd sjekker bare om eiendommen er satt.

La oss se et eksempel:

offentlig klasse Person {private Strengnavn; @Required public void setName (String name) {this.name = name; }}

Nå, den Navn av Person bean må settes i XML-konfigurasjon slik:

Vær oppmerksom på at @Krevd fungerer ikke med Java-basert @Konfigurasjon klasser som standard. Hvis du trenger å sørge for at alle eiendommene dine er angitt, kan du gjøre det når du lager bønnen i @Bønne merkede metoder.

Q16. Beskriv frontkontrollermønsteret

I frontkontrollermønsteret vil alle forespørsler først gå til frontkontrolleren i stedet for servleten. Det vil sørge for at svarene er klare og vil sende dem tilbake til nettleseren. På denne måten har vi ett sted der vi kontrollerer alt som kommer fra omverdenen.

Den fremre kontrolleren vil identifisere servletten som skal håndtere forespørselen først. Så når den får dataene tilbake fra servletten, bestemmer den hvilken visning som skal gjengis, og til slutt vil den sende den gjengitte visningen tilbake som et svar:

For å se implementeringsdetaljene, sjekk ut vår guide til frontkontrollermønsteret i Java.

Q17. Hva er modell 1 og modell 2-arkitekturer?

Modell 1 og modell 2 representerer to hyppig brukte designmodeller når det gjelder utforming av Java Web Applications.

I modell 1 kommer en forespørsel til en servlet eller JSP der den blir håndtert. Servletten eller JSP behandler forespørselen, håndterer forretningslogikk, henter og validerer data og genererer svaret:

Siden denne arkitekturen er enkel å implementere, bruker vi den vanligvis i små og enkle applikasjoner.

På den annen side er det ikke praktisk for store webapplikasjoner. Funksjonalitetene dupliseres ofte i JSPer der forretnings- og presentasjonslogikk er koblet.

Model 2 er basert på designmønsteret Model View Controller og skiller visningen fra logikken som manipulerer innholdet.

Videre kan vi skille mellom tre moduler i MVC-mønsteret: modellen, visningen og kontrolleren. Modellen representerer den dynamiske datastrukturen til en applikasjon. Det er ansvarlig for manipulering av data og forretningslogikk. Visningen er ansvarlig for visning av data, mens kontrolleren fungerer som et grensesnitt mellom de to foregående.

I modell 2 sendes en forespørsel til kontrolleren, som håndterer den nødvendige logikken for å få riktig innhold som skal vises. Kontrolleren setter deretter innholdet tilbake i forespørselen, vanligvis som en JavaBean eller en POJO. Den bestemmer også hvilken visning som skal gjengi innholdet, og til slutt sender forespørselen til den. Deretter gjengir visningen dataene:

3. Avanserte MVC-spørsmål om våren

Q18. Hva er forskjellen mellom @Kontrollør, @Komponent, @Oppbevaringssted, og @Service Kommentarer om våren?

I følge den offisielle vårdokumentasjonen, @Komponent er en generisk stereotype for alle vårstyrte komponenter. @Oppbevaringssted, @Service, og @Kontrollør er spesialiseringer av @Komponent for mer spesifikke brukstilfeller, for eksempel i henholdsvis utholdenhets-, service- og presentasjonslagene.

La oss ta en titt på spesifikke tilfeller av de tre siste:

• @Kontroller - indikerer at klassen tjener rollen som en kontroller, og oppdager @RequestMapping kommentarer i klassen
• @Service - indikerer at klassen har forretningslogikk og kaller metoder i depotlaget
• @Oppbevaringssted - indikerer at klassen definerer et datalager; jobben er å fange plattformspesifikke unntak og kaste dem på nytt som et av vårens enhetlige, ukontrollerte unntak

Q19. Hva er DispatcherServlet og ContextLoaderListener?

Enkelt sagt, i designmønsteret for frontkontrolleren er en enkelt kontroller ansvarlig for å lede innkommende HttpForespørsler til alle applikasjonens andre kontrollere og håndtere.

Vårens DispatcherServlet implementerer dette mønsteret og er derfor ansvarlig for korrekt koordinering av HttpForespørsler til høyre håndterer.

På den andre siden, ContextLoaderListener starter opp og lukker vårens rot WebApplicationContext. Det knytter livssyklusen til ApplicationContext til livssyklusen til ServletContext. Vi kan bruke den til å definere delte bønner som fungerer på tvers av forskjellige vårkontekster.

For mer informasjon om DispatcherServlet, se denne veiledningen.

Q20. Hva er en MultipartResolver og når skal vi bruke det?

De MultipartResolver grensesnitt brukes til å laste opp filer. Vårrammen gir en MultipartResolver implementering for bruk med Commons FileUpload og en annen for bruk med Servlet 3.0 flerdelt forespørselstesting.

Ved hjelp av disse kan vi støtte filopplastinger i webapplikasjonene våre.

Q21. Hva er Spring MVC Interceptor og hvordan bruker jeg det?

Spring MVC Interceptors tillater oss å fange opp en klientforespørsel og behandle den på tre steder - før håndtering, etter håndtering eller etter fullføring (når visningen er gjengitt) av en forespørsel.

Avskjæreren kan brukes til tverrgående bekymringer og for å unngå repeterende håndteringskode som logging, endring av globalt brukte parametere i vårmodell, etc.

For detaljer og ulike implementeringer, ta en titt på Introduksjon til Spring MVC HandlerInterceptor-artikkelen.

Q22. Hva er et Init Binder?

En metode kommentert med @InitBinder brukes til å tilpasse en forespørselsparameter, URI-mal og sikkerhetskopierings- / kommandoobjekter. Vi definerer det i en kontroller, og det hjelper med å kontrollere forespørselen. I denne metoden registrerer og konfigurerer vi vår tilpassede PropertyEditors, en formatering og validatorer.

Merknaden har 'verdi‘Element. Hvis vi ikke setter det, @InitBinder merkede metoder blir ringt på hver HTTP-forespørsel. Hvis vi setter verdien, vil metodene bare brukes for bestemte kommando- / skjemaattributter og / eller forespørselsparametre hvis navn tilsvarer ‘verdi‘Element.

Det er viktig å huske at et av argumentene må være WebDataBinder. Andre argumenter kan være av hvilken som helst type som behandlingsmetoder støtter, bortsett fra kommando- / skjemaobjekter og tilsvarende valideringsresultater.

Q23. Forklar et råd om kontrolleren

De @ControllerAdvice kommentar tillater oss å skrive global kode som gjelder for et bredt spekter av kontrollere. Vi kan knytte utvalg av kontrollere til en valgt pakke eller en spesifikk kommentar.

Som standard, @ControllerAdvice gjelder klassene merket med @Kontrollør (eller @RestController). Vi har også noen få egenskaper som vi bruker hvis vi vil være mer spesifikke.

Hvis vi vil begrense gjeldende klasser til en pakke, bør vi legge til navnet på pakken i kommentaren:

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

Det er også mulig å bruke flere pakker, men denne gangen må vi bruke en matrise i stedet for String.

Foruten å begrense pakken med navnet, kan vi gjøre det ved å bruke en av klassene eller grensesnittene fra den pakken:

@ControllerAdvice (basePackageClasses = MyClass.class)

Den ‘tildelbare typer‘Elementet gjelder @ControllerAdvice til de spesifikke klassene, menskommentarer‘Gjør det for spesielle kommentarer.

Det er bemerkelsesverdig å huske at vi bør bruke det sammen med @ExceptionHandler. Denne kombinasjonen vil gjøre det mulig for oss å konfigurere en global og mer spesifikk feilhåndteringsmekanisme uten å måtte implementere den hver gang for hver kontrollerklasse.

Q24. Hva gjør @ExceptionHandler Kommentar Gjør?

De @ExceptionHandler kommentar lar oss definere en metode som vil håndtere unntakene. Vi kan bruke merknaden uavhengig, men det er et langt bedre alternativ å bruke den sammen med @ControllerAdvice. Dermed kan vi sette opp en global feilhåndteringsmekanisme. På denne måten trenger vi ikke å skrive koden for unntaksbehandling i hver kontroller.

La oss se på eksemplet fra artikkelen vår om feilhåndtering for REST med vår:

@ControllerAdvice offentlig klasse RestResponseEntityExceptionHandler utvider ResponseEntityExceptionHandler {@ExceptionHandler (verdi = {IllegalArgumentException.class, IllegalStateException.class}) beskyttet ResponseEntity handleConflict (RuntimeException-forespørsel = "WebSequest"), WebRequesp = body = "ApplicationResponse = body" = "". return handleExceptionInternal (ex, bodyOfResponse, nye HttpHeaders (), HttpStatus.CONFLICT, forespørsel); }}

Vi bør også merke oss at dette vil gi @ExceptionHandler metoder til alle kontrollere som kaster IllegalArgumentException eller IllegalStateException. Unntakene erklært med @ExceptionHandler skal samsvare med unntaket som brukes som argument for metoden. Ellers vil unntaksløsningsmekanismen mislykkes ved kjøretid.

En ting å huske på her er at det er mulig å definere mer enn en @ExceptionHandler for samme unntak. Vi kan ikke gjøre det i samme klasse, men siden våren ville klage ved å kaste et unntak og mislykkes ved oppstart.

På den andre siden, hvis vi definerer de i to separate klasser, vil applikasjonen starte, men den vil bruke den første håndtereren den finner, muligens feil.

Q25. Unntakshåndtering i webapplikasjoner

Vi har tre alternativer for håndtering av unntak i Spring MVC:

• per unntak
• per kontroller
• globalt

Hvis et unhåndtert unntak blir kastet under behandling av forespørsler på nettet, vil serveren returnere et HTTP 500-svar. For å forhindre dette, vi bør kommentere noen av våre tilpassede unntak med @ResponseStatus kommentar. Denne typen unntak løses av HandlerExceptionResolver.

Dette vil føre til at serveren returnerer et passende HTTP-svar med den angitte statuskoden når en kontrollermetode gir vårt unntak. Vi bør huske på at vi ikke skal håndtere unntaket vårt et annet sted for at denne tilnærmingen skal fungere.

En annen måte å håndtere unntakene på er å bruke @ExceptionHandler kommentar. Vi legger til @ExceptionHandler metoder til hvilken som helst kontroller og bruke dem til å håndtere unntakene som kastes fra innsiden av kontrolleren. Disse metodene kan håndtere unntak uten @ResponseStatus kommentar, omdirigere brukeren til en dedikert feilvisning, eller bygg et helt tilpasset feilrespons.

Vi kan også sende inn servletrelaterte objekter (HttpServletRequest, HttpServletResponse, HttpSession, og Rektor) som parametere for behandlingsmetodene. Men vi bør huske at vi ikke kan sette Modell objekt som parameter direkte.

Det tredje alternativet for håndtering av feil er av @ControllerAdvice klasser. Det vil tillate oss å bruke de samme teknikkene, bare denne gangen på applikasjonsnivå og ikke bare til den bestemte kontrolleren. For å aktivere dette må vi bruke @ControllerAdvice og @ExceptionHandler sammen. På denne måten håndterer unntakshåndterere unntak fra alle kontrollere.

For mer detaljert informasjon om dette emnet, gå gjennom artikkelen Feilhåndtering for REST med vår.

4. Konklusjon

I denne artikkelen har vi utforsket noen av Spring MVC-relaterte spørsmål som kan komme opp på det tekniske intervjuet for Spring-utviklere. Du bør ta hensyn til disse spørsmålene som utgangspunkt for videre forskning, siden dette på ingen måte er en uttømmende liste.

Vi ønsker deg lykke til i kommende intervjuer!