streamalism.org

1. Introduktion

Spring MVC er den oprindelige webramme fra Spring bygget på Servlet API. Det giver Model-View-Controller-arkitektur, der kan bruges til at udvikle fleksible webapplikationer.

I denne vejledning vil vi fokusere på de spørgsmål, der er relateret til det, da det ofte er et emne på et forårssamtale om jobsamtale.

For flere spørgsmål om Spring Framework kan du tjekke en anden Spring-relateret artikel i vores interviewspørgsmålsserie.

2. Grundlæggende Spring MVC-spørgsmål

Q1. Hvorfor skal vi bruge fjeder-MVC?

Spring MVC implementerer en klar adskillelse af bekymringer, der giver os mulighed for let at udvikle og enhedsteste vores applikationer.

Begreberne som:

• Dispatcher Servlet
• Controllere
• Se Resolvere
• Visninger, modeller
• ModelAndView
• Model- og sessionsattributter

er helt uafhængige af hinanden, og de er kun ansvarlige for én ting.

Derfor, MVC giver os ret stor fleksibilitet. Det er baseret på grænseflader (med medfølgende implementeringsklasser), og vi kan konfigurere alle dele af rammen ved hjælp af brugerdefinerede grænseflader.

En anden vigtig ting er, at vi ikke er bundet til en bestemt visningsteknologi (for eksempel JSP), men vi har mulighed for at vælge blandt dem, vi bedst kan lide.

Også, vi bruger ikke Spring MVC kun til udvikling af webapplikationer, men også i oprettelsen af ​​RESTful webtjenester.

Q2. Hvad er rollen for @Autowired Kommentar?

Det @Autowired annotering kan bruges med felter eller metoder til injektion af en bønne efter type. Denne kommentar giver Spring mulighed for at løse og indsprøjte samarbejdende bønner i din bønne.

For flere detaljer, se vejledningen om @Autowired om foråret.

Q3. Forklar en modelattribut

Det @ModelAttribute kommentar er en af ​​de vigtigste kommentarer i Spring MVC. Det binder en metodeparameter eller en metodereturværdi til en navngivet modelattribut og udsætter den derefter for en webvisning.

Hvis vi bruger det på metodeniveau, angiver det formålet med denne metode er at tilføje en eller flere modelattributter.

På den anden side angiver det, at når det bruges som et metodeargument, skal argumentet hentes fra modellen. Når det ikke er til stede, skal vi først instantiere det og derefter tilføje det til modellen. Når de er til stede i modellen, skal vi udfylde argumenterne fra alle anmodningsparametre, der har matchende navne.

Mere om denne kommentar kan findes i vores artikel relateret til @ModelAttribute kommentar.

Q4. Forklar forskellen mellem @Kontrol og @RestController?

Den største forskel mellem @Kontrol og @RestController bemærkninger er det det @ResponseBody annotering er automatisk inkluderet i @RestController. Dette betyder, at vi ikke behøver at kommentere vores handlermetoder med @ResponseBody. Vi er nødt til at gøre dette i en @Kontrol klasse, hvis vi vil skrive svarstypen direkte til HTTP-responsorganet.

Q5. Beskriv a PathVariable

Vi kan bruge @PathVariable annotation som en behandlingsmetodeparameter for at udtrække værdien af ​​en URI-skabelonvariabel.

For eksempel, hvis vi ønsker at hente en bruger ved id fra www.mysite.com/user/123, skal vi kortlægge vores metode i controlleren som /bruger ID}:

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

Det @PathVariable har kun ét element navngivet værdi. Det er valgfrit, og vi bruger det til at definere navnet på URI-skabelonvariablen. Hvis vi udelader værdielementet, skal navnet på URI-skabelonvariablen matche metodeparameternavnet.

Det er også tilladt at have flere @PathVariable kommentarer, enten ved at erklære dem efter hinanden:

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

eller lægge dem alle i en Kort eller MultiValueMap:

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

Q6. Validering ved hjælp af fjeder-MVC

Spring MVC understøtter JSR-303-specifikationer som standard. Vi er nødt til at tilføje JSR-303 og dens afhængigheds implementering til vores Spring MVC-applikation. Hibernate Validator er for eksempel en af ​​de JSR-303-implementeringer, vi har til rådighed.

JSR-303 er en specifikation af Java API til bønnevalidering, en del af Jakarta EE og JavaSE, som sikrer, at egenskaber for en bønne opfylder specifikke kriterier ved hjælp af annoteringer som f.eks. @NotNull, @Minog @Max. Mere om validering findes i artiklen om grundlæggende validering af Java Bean.

Foråret tilbyder @Validator kommentar og Bindende resultat klasse. Det Validator implementering vil medføre fejl i håndteringsmetoden til controller-anmodning, når vi har ugyldige data. Så kan vi bruge Bindende resultat klasse for at få disse fejl.

Udover at bruge de eksisterende implementeringer kan vi lave vores egne. For at gøre det opretter vi først en kommentar, der overholder JSR-303-specifikationerne. Derefter implementerer vi Validator klasse. En anden måde ville være at implementere Spring's Validator interface og indstil det som validator via @InitBinder kommentar i Controller klasse.

For at se, hvordan du implementerer og bruger dine egne valideringer, se vejledningen vedrørende Custom Validation i Spring MVC.

Q7. Hvad er @RequestBody og @ResponseBody?

Det @RequestBody annotation, der bruges som en behandlingsmetodeparameter, binder HTTP-anmodningslegemet til en overførsel eller et domæneobjekt. Spring deserialiserer automatisk indgående HTTP-anmodning til Java-objektet ved hjælp af Http Message Converters.

Når vi bruger @ResponseBody anmærkning om en behandlingsmetode i Spring MVC-controlleren, det indikerer, at vi skriver metodens returtype direkte til HTTP-responsorganet. Vi lægger det ikke i en Modelog Spring fortolker ikke som et visningsnavn.

Tjek venligst artiklen på @RequestBody og @ResponseBody for at se flere detaljer om disse kommentarer.

Q8. Forklare Model, ModelMap og ModelAndView?

Det Model interface definerer en holder til modelattributter. Det ModelMap har et lignende formål med evnen til at videregive en samling værdier. Det behandler derefter disse værdier som om de var inden for en Kort. Vi skal bemærke, at i Model (ModelMap) vi kan kun gemme data. Vi indsætter data og returnerer et visningsnavn.

På den anden side, med ModelAndView, returnerer vi selve objektet. Vi sætter alle de krævede oplysninger, som dataene og visningsnavnet, i det objekt, vi returnerer.

Du kan finde flere detaljer i artiklen på Model, ModelMapog ModelView.

Q9. Forklare SessionAttributter og SessionAttribute

Det @SessionAttributter annotation bruges til at gemme modelattributten i brugerens session. Vi bruger det på controllerniveau som vist i vores artikel om Sessionsattributter i Spring MVC:

@Controller @RequestMapping ("/ sessionattributter") @SessionAttributter ("todos") offentlig klasse TodoControllerWithSessionAttributter {@GetMapping ("/ form") offentlig String showForm (Modelmodel, @ModelAttribute ("todos") TodoList todos) {// metode body return "sessionattributform"; } // andre metoder}

I det foregående eksempel er modelattributten 'todos'Tilføjes til sessionen, hvis den @ModelAttribute og @SessionAttributter har samme navn attribut.

Hvis vi vil hente den eksisterende attribut fra en session, der administreres globalt, bruger vi @SessionAttribute kommentar som en metodeparameter:

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

Q10. Hvad er formålet med @EnableWebMVC?

Det @EnableWebMvc annotations formål er at aktivere Spring MVC via Java-konfiguration. Det svarer til i en XML-konfiguration. Denne kommentar importerer Spring MVC Configuration fra WebMvcConfigurationSupport. Det muliggør support til @Kontrol-anmeldte klasser, der bruger @RequestMapping for at kortlægge indgående anmodninger til en behandlingsmetode.

Du kan lære mere om dette og lignende kommentarer i vores guide til foråret @ Aktiver Kommentarer.

Q11. Hvad er ViewResolver om foråret?

Det ViewResolver gør det muligt for et program at gengive modeller i browseren - uden at binde implementeringen til en bestemt visningsteknologi - ved at kortlægge visningsnavne til faktiske visninger.

For flere detaljer om ViewResolver, kig på vores guide til ViewResolver i Spring MVC.

Q12. Hvad er Bindende resultat?

Bindende resultat er en grænseflade fra org.springframework.validation pakke, der repræsenterer bindende resultater. Vi kan bruge det til at opdage og rapportere fejl i den indsendte form. Det er let at påberåbe sig - vi skal bare sikre, at vi sætter det som en parameter lige efter det formularobjekt, vi validerer. Det valgfri Model parameter skal komme efter Bindende resultat, som det kan ses i brugervejledningen til brugerdefineret validering:

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

Når foråret ser @Gyldig bemærkning, det forsøger først at finde valideringen til det objekt, der valideres. Derefter afhenter det valideringsanmærkningerne og påkalder validatoren. Endelig vil det placere fundne fejl i Bindende resultat og tilføj sidstnævnte til visningsmodellen.

Q13. Hvad er et formstøtteobjekt?

Formularbaggrundsobjektet eller et kommandoobjekt er bare en POJO, der indsamler data fra den form, vi sender.

Vi skal huske på, at det ikke indeholder nogen logik, kun data.

For at lære at bruge formstøtteobjekt med formularerne i Spring MVC, se venligst vores artikel om Forms in Spring MVC.

Q14. Hvad er rollen for @Kvalifikator Kommentar?

Det bruges samtidigt med @Autowired kommentar for at undgå forvirring, når der er flere forekomster af en bønnetype.

Lad os se et eksempel. Vi erklærede to lignende bønner i XML-konfiguration:

Når vi prøver at binde bønnen, får vi en org.springframework.beans.factory.NoSuchBeanDefinitionException. For at rette det skal vi bruge @Kvalifikator at fortælle foråret om, hvilken bønne der skal kobles til:

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

Q15. Hvad er rollen for @Krævet Kommentar?

Det @Krævet annotering bruges på settermetoder, og det indikerer, at den bønneegenskab, der har denne kommentar, skal udfyldes på konfigurationstidspunktet. Ellers kaster fjedercontaineren en BeanInitializationException undtagelse.

Også, @Krævet adskiller sig fra @Autowired - da det er begrænset til en setter, mens @Autowired er ikke. @Autowired kan også bruges til at tilslutte en konstruktør og et felt, mens @Krævet kontrollerer kun, om ejendommen er indstillet.

Lad os se et eksempel:

offentlig klasse person {privat strengnavn; @Required public void setName (String name) {this.name = name; }}

Nu, den navn af Person bean skal indstilles i XML-konfiguration sådan:

Bemærk, at @Krævet fungerer ikke med Java-baseret @Konfiguration klasser som standard. Hvis du har brug for at sikre dig, at alle dine egenskaber er indstillet, kan du gøre det, når du opretter bønnen i @Bønne annoterede metoder.

Q16. Beskriv det forreste controller mønster

I frontcontroller-mønsteret går alle anmodninger først til frontcontrolleren i stedet for servlet. Det sørger for, at svarene er klar, og sender dem tilbage til browseren. På denne måde har vi ét sted, hvor vi styrer alt, hvad der kommer fra omverdenen.

Den forreste controller identificerer den servlet, der skal håndtere anmodningen først. Derefter, når den henter dataene tilbage fra servleten, bestemmer den, hvilken visning der skal gengives, og endelig sender den den gengivne visning tilbage som et svar:

For at se implementeringsoplysningerne, se vores guide til frontcontroller-mønsteret i Java.

Q17. Hvad er model 1 og model 2-arkitekturer?

Model 1 og Model 2 repræsenterer to hyppigt anvendte designmodeller, når det gælder design af Java-webapplikationer.

I model 1 kommer en anmodning til en servlet eller JSP, hvor den bliver håndteret. Servlet eller JSP behandler anmodningen, håndterer forretningslogik, henter og validerer data og genererer svaret:

Da denne arkitektur er let at implementere, bruger vi den normalt i små og enkle applikationer.

På den anden side er det ikke praktisk for store webapplikationer. Funktionaliteterne duplikeres ofte i JSP'er, hvor forretnings- og præsentationslogik er koblet.

Model 2 er baseret på designmønsteret Model View Controller og adskiller visningen fra logikken, der manipulerer indholdet.

Desuden kan vi skelne mellem tre moduler i MVC-mønsteret: modellen, visningen og controlleren. Modellen repræsenterer en applikations dynamiske datastruktur. Det er ansvarlig for manipulation af data og forretningslogik. Visningen er ansvarlig for visning af data, mens controlleren fungerer som en grænseflade mellem de to foregående.

I model 2 sendes en anmodning til controlleren, som håndterer den krævede logik for at få det rigtige indhold, der skal vises. Controlleren sætter derefter indholdet tilbage i anmodningen, typisk som en JavaBean eller en POJO. Det beslutter også, hvilken visning der skal gengive indholdet, og til sidst videresender anmodningen til det. Derefter gengiver visningen dataene:

3. Avancerede MVC-spørgsmål om foråret

Q18. Hvad er forskellen mellem @Kontrol, @Komponent, @Repository, og @Service Kommentarer om foråret?

Ifølge den officielle foråret dokumentation, @Komponent er en generisk stereotype for enhver Spring-managed komponent. @Repository, @Serviceog @Kontrol er specialiseringer af @Komponent til mere specifikke brugssager, for eksempel i henholdsvis persistens-, service- og præsentationslagene.

Lad os se på specifikke brugssager fra de sidste tre:

• @Controller - angiver, at klassen tjener rollen som en controller og registrerer @RequestMapping kommentarer inden for klassen
• @Service - angiver, at klassen har forretningslogik og kalder metoder i lageret
• @Datalager - angiver, at klassen definerer et datalager; dets opgave er at fange platformsspecifikke undtagelser og genkaste dem som en af ​​Spring's samlede, ukontrollerede undtagelser

Q19. Hvad er DispatcherServlet og ContextLoaderListener?

Kort sagt, i Front Controller designmønsteret er en enkelt controller ansvarlig for at dirigere indgående HttpForespørgsler til alle applikationens andre controllere og håndterere.

Forårets DispatcherServlet implementerer dette mønster og er derfor ansvarlig for korrekt koordinering af HttpForespørgsler til højre håndtering.

På den anden side, ContextLoaderListener starter op og lukker forårets rod WebApplicationContext. Det binder livscyklussen for ApplicationContext til livscyklussen for ServletContext. Vi kan bruge den til at definere delte bønner, der arbejder på tværs af forskellige Spring-sammenhænge.

For flere detaljer om DispatcherServlet, se venligst denne vejledning.

Q20. Hvad er en MultipartResolver og hvornår skal vi bruge det?

Det MultipartResolver interface bruges til at uploade filer. Forårsrammen giver en MultipartResolver implementering til brug med Commons FileUpload og en anden til brug med Servlet 3.0 multipart anmodningsparsering.

Ved hjælp af disse kan vi understøtte filuploads i vores webapplikationer.

Q21. Hvad er Spring MVC Interceptor og hvordan man bruger det?

Spring MVC Interceptors giver os mulighed for at opfange en klientanmodning og behandle den tre steder - inden håndtering, efter håndtering eller efter afslutning (når visningen er gengivet) af en anmodning.

Interceptoren kan bruges til tværgående bekymringer og for at undgå gentagne handlingskoder som logning, ændring af globalt anvendte parametre i Spring-model osv.

For detaljer og forskellige implementeringer, se på Introduktion til Spring MVC HandlerInterceptor-artiklen.

Q22. Hvad er et Init Binder?

En metode, der er kommenteret med @InitBinder bruges til at tilpasse en anmodningsparameter, URI-skabelon og backing / kommandoobjekter. Vi definerer det i en controller, og det hjælper med at kontrollere anmodningen. I denne metode registrerer og konfigurerer vi vores brugerdefinerede PropertyEditors, en formatering og validatorer.

Annotationen har 'værdi'Element. Hvis vi ikke indstiller det, @InitBinder annoterede metoder kaldes på hver HTTP-anmodning. Hvis vi indstiller værdien, anvendes metoderne kun til bestemte kommando- / formattributter og / eller anmodningsparametre, hvis navne svarer til 'værdi'Element.

Det er vigtigt at huske, at et af argumenterne skal være WebDataBinder. Andre argumenter kan være af enhver type, som behandlingsmetoder understøtter, undtagen kommando / formobjekter og tilsvarende valideringsresultatobjekter.

Q23. Forklar en controller-rådgivning

Det @ControllerAdvice annotering giver os mulighed for at skrive global kode, der gælder for en bred vifte af controllere. Vi kan binde rækkevidden af ​​controllere til en valgt pakke eller en bestemt kommentar.

Som standard, @ControllerAdvice gælder for de klasser, der er kommenteret med @Kontrol (eller @RestController). Vi har også et par egenskaber, som vi bruger, hvis vi vil være mere specifikke.

Hvis vi ønsker at begrænse gældende klasser til en pakke, skal vi føje navnet på pakken til kommentaren:

@ControllerAdvice ("min.pakke") @ControllerAdvice (værdi = "min.pakke") @ControllerAdvice (basePackages = "min.pakke")

Det er også muligt at bruge flere pakker, men denne gang skal vi bruge en matrix i stedet for Snor.

Udover at begrænse pakken med dens navn, kan vi gøre det ved at bruge en af ​​klasser eller grænseflader fra den pakke:

@ControllerAdvice (basePackageClasses = MyClass.class)

Det 'tildelbare typer'Elementet anvender @ControllerAdvice til de specifikke klasser, menskommentarer'Gør det til bestemte kommentarer.

Det er bemærkelsesværdigt at huske, at vi skal bruge det sammen med @ExceptionHandler. Denne kombination giver os mulighed for at konfigurere en global og mere specifik fejlhåndteringsmekanisme uden behov for at implementere den hver gang for hver controller-klasse.

Q24. Hvad betyder det @ExceptionHandler Kommentar Gør?

Det @ExceptionHandler annotation giver os mulighed for at definere en metode, der håndterer undtagelserne. Vi bruger muligvis kommentaren uafhængigt, men det er en langt bedre mulighed for at bruge den sammen med @ControllerAdvice. Således kan vi oprette en global fejlhåndteringsmekanisme. På denne måde behøver vi ikke skrive koden til undtagelseshåndtering inden for hver controller.

Lad os se på eksemplet fra vores artikel om fejlhåndtering til REST med forår:

@ControllerAdvice offentlig klasse RestResponseEntityExceptionHandler udvider ResponseEntityExceptionHandler {@ExceptionHandler (værdi = {IllegalArgumentException.class, IllegalStateException.class}) beskyttet ResponseEntity handleConflict (RuntimeException-anmodning). return handleExceptionInternal (ex, bodyOfResponse, nye HttpHeaders (), HttpStatus.CONFLICT, anmodning); }}

Vi skal også bemærke, at dette vil give @ExceptionHandler metoder til alle controllere, der kaster IllegalArgumentException eller IllegalStateException. De undtagelser, der er erklæret med @ExceptionHandler skal matche den undtagelse, der bruges som argument for metoden. Ellers vil undtagelsesløsningsmekanismen mislykkes ved kørsel.

En ting at huske på her er, at det er muligt at definere mere end en @ExceptionHandler for den samme undtagelse. Vi kan ikke gøre det i samme klasse, men siden foråret ville klage ved at kaste en undtagelse og fejle ved opstart.

På den anden side, Hvis vi definerer dem i to separate klasser, starter applikationen, men den bruger den første handler, den finder, muligvis den forkerte.

Q25. Undtagelse Håndtering i webapplikationer

Vi har tre muligheder for håndtering af undtagelser i Spring MVC:

• pr. undtagelse
• pr. controller
• globalt

Hvis en uhåndteret undtagelse smides under behandling af webanmodninger, returnerer serveren et HTTP 500-svar. For at forhindre dette, vi skal kommentere enhver af vores brugerdefinerede undtagelser med @ResponseStatus kommentar. Denne form for undtagelser løses ved HandlerExceptionResolver.

Dette får serveren til at returnere et passende HTTP-svar med den angivne statuskode, når en controller-metode kaster vores undtagelse. Vi skal huske på, at vi ikke skal håndtere vores undtagelse et andet sted for, at denne tilgang fungerer.

En anden måde at håndtere undtagelserne på er at bruge @ExceptionHandler kommentar. Vi tilføjer @ExceptionHandler metoder til enhver controller og bruge dem til at håndtere de undtagelser, der kastes inde fra den controller. Disse metoder kan håndtere undtagelser uden @ResponseStatus kommentar, omdirigere brugeren til en dedikeret fejlvisning eller opbygge et helt tilpasset fejlsvar.

Vi kan også videregive de servlet-relaterede objekter (HttpServletRequest, HttpServletResponse, HttpSessionog Rektor) som parametre for behandlingsmetoderne. Men vi skal huske, at vi ikke kan sætte Model objekt som parameter direkte.

Den tredje mulighed for håndtering af fejl er af @ControllerAdvice klasser. Det giver os mulighed for at anvende de samme teknikker, kun denne gang på applikationsniveau og ikke kun til den bestemte controller. For at aktivere dette skal vi bruge @ControllerAdvice og @ExceptionHandler sammen. På denne måde håndterer undtagelseshåndterere undtagelser fra enhver controller.

For mere detaljerede oplysninger om dette emne, gå gennem artiklen Fejlhåndtering til REST med forår.

4. Konklusion

I denne artikel har vi undersøgt nogle af Spring MVC-relaterede spørgsmål, der kunne komme op i det tekniske interview for Spring-udviklere. Du bør tage disse spørgsmål i betragtning som udgangspunkt for yderligere forskning, da dette på ingen måde er en udtømmende liste.

Vi ønsker dig held og lykke i alle kommende interviews!