streamalism.org

1. Bemutatkozás

A Spring MVC a Spring eredeti webes keretrendszere, amely a Servlet API-ra épül. Ez biztosítja a Model-View-Controller architektúrát, amely rugalmas webalkalmazások fejlesztésére használható.

Ebben az oktatóanyagban a vele kapcsolatos kérdésekre fogunk összpontosítani, mivel ez gyakran egy tavaszi fejlesztői állásinterjú témája.

Ha további kérdései vannak a tavaszi keretrendszerrel kapcsolatban, olvassa el interjúk kérdéssorozatunk másik tavaszi cikkét.

2. Alapvető tavaszi MVC kérdések

Q1. Miért használjuk a tavaszi MVC-t?

A tavaszi MVC az aggodalmak világos elkülönítését valósítja meg, amely lehetővé teszi számunkra, hogy az alkalmazásokat könnyedén kifejlesszük és egységesen teszteljük.

Az olyan fogalmak, mint:

• Dispatcher Servlet
• Vezérlők
• Megoldók megtekintése
• Nézetek, modellek
• ModelAndView
• Modell és munkamenet attribútumok

teljesen függetlenek egymástól, és csak egy dologért felelnek.

Ebből kifolyólag, Az MVC elég nagy rugalmasságot biztosít számunkra. Ez interfészeken alapul (a megadott megvalósítási osztályokkal), és a keretrendszer minden részét egyedi interfészek használatával konfigurálhatjuk.

Egy másik fontos dolog az, hogy nem vagyunk kötve egy adott nézett technológiához (például JSP), de lehetőségünk van a legjobban tetszenek közül választani.

Is, nem használjuk a Spring MVC-t csak a webalkalmazások fejlesztésében, hanem a RESTful webszolgáltatások létrehozásában is.

Q2. Mi a szerepe a @Autowired Megjegyzés?

A @Autowired az annotáció használható mezőkkel vagy módszerekkel a bab típus szerinti injektálására. Ez az annotáció lehetővé teszi a Spring számára, hogy oldja meg az injekciót, és beadja az együttműködő babot a babjába.

További részletekért olvassa el a bemutatót @Autowired tavasszal.

Q3. Magyarázza el a modellattribútumot

A @ModelAttribute az annotáció az egyik legfontosabb annotáció a Spring MVC-ben. A metódus-paramétert vagy a metódus-visszatérési értéket megnevezett modellattribútumhoz köti, majd egy webnézetbe teszi ki.

Ha a módszer szintjén használjuk, akkor ez azt jelzi, hogy a módszer célja egy vagy több modellattribútum hozzáadása.

Másrészt, ha metódus argumentumként használják, akkor azt jelzi, hogy az argumentumot le kell tölteni a modellből. Ha nincs jelen, akkor először példányosítanunk kell, majd hozzá kell adnunk a modellhez. Ha jelen van a modellben, akkor fel kell töltenünk az argumentum mezőket minden olyan kérési paraméterből, amelynek egyező neve van.

Erről az annotációról bővebben a @ModelAttribute annotáció.

Q4. Magyarázza el a különbséget @Vezérlő és @RestController?

A fő különbség a @Vezérlő és @RestController annotációk az a @ResponseBody a kommentár automatikusan bekerül a @RestController. Ez azt jelenti, hogy nem kell jegyeznünk a kezelő metódusait a @ResponseBody. Ezt meg kell tennünk a @Vezérlő osztály, ha a válasz típusát közvetlenül a HTTP válasz testhez akarjuk írni.

Q5. Írja le a PathVariable

Használhatjuk a @PathVariable annotáció mint kezelő metódus paraméter az URI sablon változó értékének kinyerése érdekében.

Például, ha egy felhasználót azonosítóval szeretnénk lekérni a www.mysite.com/user/123, módszerünket a vezérlőben kell feltérképeznünk /Felhasználói azonosító}:

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

A @PathVariable csak egy eleme van megnevezve érték. Ez nem kötelező, és az URI sablon változó nevének meghatározásához használjuk. Ha kihagyjuk az érték elemet, akkor az URI sablon változó nevének meg kell egyeznie a metódus paraméter nevével.

Az is megengedett, hogy több legyen @PathVariable feliratokat, vagy egymás után deklarálva:

@RequestMapping ("/ user / {userId} / név / {felhasználónév}") public String handleRequest (@PathVariable String userId, @PathVariable String felhasználónév, modelltérkép) {}

vagy mindet beleteszi a Térkép vagy MultiValueMap:

@RequestMapping ("/ user / {userId} / név / {felhasználónév}") public String handleRequest (@PathVariable Map varsMap, Model map) {}

Q6. Érvényesítés a rugós MVC segítségével

A Spring MVC alapértelmezés szerint támogatja a JSR-303 specifikációkat. Hozzá kell adnunk a JSR-303-at és annak megvalósítási függőségeit a tavaszi MVC alkalmazásunkhoz. A Hibernate Validator például az egyik rendelkezésünkre álló JSR-303 megvalósítás.

A JSR-303 a Java API specifikációja a babellenőrzéshez, a Jakarta EE és a JavaSE része, amely olyan kommentárok használatával biztosítja, hogy a bab tulajdonságai megfelelnek a meghatározott kritériumoknak. @Nem nulla, @Min, és @Max. Az érvényesítésről a Java Bean Validation Basics cikkben olvashat bővebben.

A tavasz a @Validator kommentár és a BindingResult osztály. A Validator A megvalósítás hibákat fog felvetni a vezérlő kéréskezelő módszerében, ha érvénytelen adatokkal rendelkezünk. Akkor használhatjuk a BindingResult osztály, hogy megkapja ezeket a hibákat.

A meglévő megvalósítások használata mellett saját magunk is elkészíthetjük. Ehhez először hozzunk létre egy olyan jegyzetet, amely először megfelel a JSR-303 specifikációknak. Ezután megvalósítjuk a Validator osztály. Egy másik módszer a Spring's megvalósítása lenne Validator interfészen keresztül állítsa be validátorként @InitBinder annotáció Vezérlő osztály.

A saját ellenőrzések megvalósításának és használatának megtekintéséhez olvassa el a tavaszi MVC egyéni érvényesítésével kapcsolatos oktatóanyagot.

Q7. Mik a @ RequestBody és a @ResponseBody?

A @ RequestBody A kezelő metódus paramétereként használt megjegyzés a HTTP Request törzset átviteli vagy tartományi objektumhoz köti. A Spring automatikusan deszerializálja a bejövő HTTP kérést a Java objektumra a Http Message Converter segítségével.

Amikor használjuk a @ResponseBody a Spring MVC vezérlő kezelői metódusának jelölése azt jelzi, hogy a metódus visszatérési típusát közvetlenül a HTTP válasz testhez írjuk. Nem teszünk bele egy Modell, és a Spring nem értelmezi nézetnévként.

Kérjük, olvassa el a cikket @ RequestBody és @ResponseBody hogy további részleteket lásson ezekről a kommentárokról.

Q8. Magyarázza el Modell, ModelMap és ModelAndView?

A Modell Az interfész meghatározza a modellattribútumok birtokosát. A ModelMap hasonló célja van, képes átadni egy értékgyűjteményt. Ezután úgy kezeli ezeket az értékeket, mintha a Térkép. Meg kell jegyeznünk, hogy a Modell (ModelMap) csak adatokat tárolhatunk. Adatokat helyezünk el, és egy nézet nevét adjuk vissza.

Másrészről, a ... val ModelAndView, visszaadjuk magát az objektumot. Az összes szükséges információt, például az adatokat és a nézet nevét, beállítjuk a visszatérő objektumban.

További részletek a cikkben találhatók Modell, ModelMap, és ModelView.

Q9. Magyarázza el SessionAttributes és SessionAttribute

A @SessionAttributes az annotáció a modellattribútum tárolására szolgál a felhasználó munkamenetében. A kontroller osztály szintjén használjuk, amint azt a tavaszi MVC munkamenetattribútumairól szóló cikkünk is mutatja:

@Controller @RequestMapping ("/ sessionattributes") @SessionAttributes ("todos") public class TodoControllerWithSessionAttributes {@GetMapping ("/ form") public String showForm (Model model, @ModelAttribute ("todos") TodoList todos) {// módszer body return "sessionattributesform"; } // egyéb módszerek}

Az előző példában a modell attribútum ’todos’Hozzáadódik a munkamenethez, ha a @ModelAttribute és a @SessionAttributes ugyanaz a név attribútum.

Ha le akarjuk szerezni a meglévő attribútumot egy globálisan kezelt munkamenetből, akkor ezt használjuk @SessionAttribute annotáció mint metódus paraméter:

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

Q10. Mi a célja @EnableWebMVC?

A @EnableWebMvc az annotáció célja a Spring MVC engedélyezése Java konfiguráción keresztül. Ez egyenértékű XML konfigurációban. Ez a megjegyzés a tavaszi MVC-konfigurációt importálja innen WebMvcConfigurationSupport. Lehetővé teszi a @Vezérlő-jegyzet nélküli osztályok, amelyek használják @RequestMapping a beérkező kérések lekezelésére egy kezelő módszerre.

Erről és a hasonló kommentárokról többet megtudhat a Tavaszi útmutatónkban @Engedélyezze Megjegyzések.

Q11. Mi a ViewResolver tavasszal?

A ViewResolver lehetővé teszi egy alkalmazás számára, hogy modelleket jelenítsen meg a böngészőben - anélkül, hogy a megvalósítást egy speciális nézettechnológiához kötnék - a nézetek nevének a tényleges nézetekhez való hozzárendelésével.

További részletek a ViewResolver, tekintse meg a ViewResolver útmutatóját a tavaszi MVC-ben.

Q12. Mi a BindingResult?

BindingResult egy interfész a org.springframework.validation csomag, amely kötelező eredményeket képvisel. Használhatjuk a beküldött űrlap hibáinak észlelésére és jelentésére. Könnyen meghívható - csak azt kell biztosítanunk, hogy paraméterként tegyük fel közvetlenül az érvényesítendő űrlapobjektum után. Az opcionális Modell paraméternek a BindingResult, amint az az egyedi ellenőrző oktatóanyagban is látható:

@PostMapping ("/ user") public String submitForm (@Valid NewUserForm newUserForm, BindingResult result, Model model) {if (result.hasErrors ()) {return "userHome"; } model.addAttribute ("üzenet", "Érvényes forma"); return "userHome"; }

Amikor Tavasz meglátja a @Érvényes megjegyzés, akkor először megpróbálja megtalálni az érvényesítendő objektum érvényesítőjét. Ezután felveszi az érvényesítési kommentárokat, és meghívja az érvényesítőt. Végül a talált hibákat fogja beilleszteni a BindingResult és az utóbbit adja hozzá a nézet modelljéhez.

Q13. Mi az űrlapot támogató objektum?

Az űrlaptámogató objektum vagy a Parancsobjektum csak egy POJO, amely adatokat gyűjt az általunk beküldött űrlapból.

Nem szabad megfeledkeznünk arról, hogy nem tartalmaz semmilyen logikát, csak adatokat.

Ha meg szeretné tudni, hogyan kell használni az űrlaptámogató objektumot a Spring MVC űrlapjaival, olvassa el cikkünket a Spring MVC űrlapokról.

Q14. Mi a szerepe a @ Minősítő Megjegyzés?

Egyszerre használják a @Autowired annotáció az összetévesztés elkerülése érdekében, ha több bab típusú példány van jelen.

Lássunk egy példát. Két hasonló babot deklaráltunk XML konfigurációban:

Amikor megpróbáljuk bekötni a babot, kapunk egy org.springframework.beans.factory.NoSuchBeanDefinitionException. A javításhoz használnunk kell @ Minősítő hogy elmondja Springnek, hogy melyik babot kell bekötni:

@Autowired @Qualifier ("person1") magánszemély;

Q15. Mi a szerepe a @Kívánt Megjegyzés?

A @Kívánt a szetter metódusoknál az annotációt használják, és ez azt jelzi, hogy a bab tulajdonságot, amely rendelkezik ezzel az annotációval, be kell tölteni a konfiguráláskor. Ellenkező esetben a tavaszi konténer a BeanInitializationException kivétel.

Is, @Kívánt különbözik @Autowired - mivel szetterre korlátozódik, míg @Autowired nem. @Autowired használható konstruktorral és mezővel való huzalozásra is, míg @Kívánt csak akkor ellenőrzi, hogy a tulajdonság be van-e állítva.

Lássunk egy példát:

public class Személy {private String név; @Kötelező public void setName (karakterlánc neve) {this.name = név; }}

Most a név a Személy A babot az XML konfigurációban kell beállítani, így:

Kérjük, vegye figyelembe, hogy @Kívánt nem működik Java alapú @ Konfiguráció osztályok alapértelmezés szerint. Ha meg kell győződnie arról, hogy az összes tulajdonság be van állítva, akkor ezt megteheti, amikor létrehozza a babot a @Bab kommentált módszerek.

Q16. Írja le az elülső vezérlő mintáját

Az elülső vezérlő mintájában minden kérés először az elülső vezérlőhöz kerül a szervlet helyett. Meggyőződik arról, hogy a válaszok készen állnak, és visszaküldi őket a böngészőbe. Így van egy helyünk, ahol mindent irányítunk, ami a külvilágból származik.

Az elülső vezérlő azonosítja azt a szervletet, amelynek először kezelnie kell a kérést. Ezután, amikor visszakapja az adatokat a szervletről, eldönti, hogy melyik nézetet adja vissza, és végül válaszként visszaküldi a renderelt nézetet:

A megvalósítás részleteinek megtekintéséhez olvassa el a Java-ban található vezérlő mintáját.

Q17. Mi az 1. és 2. modell architektúrája?

Az 1. és a 2. modell két gyakran használt tervezési modellt képvisel, amikor a Java webalkalmazások tervezéséről van szó.

Az 1. modellben egy kérelem egy szervlethez vagy JSP-hez érkezik, ahol kezelik. A kiszolgáló kisalkalmazás vagy a JSP feldolgozza a kérést, kezeli az üzleti logikát, beolvassa és érvényesíti az adatokat, és létrehozza a választ:

Mivel ezt az architektúrát könnyű megvalósítani, általában apró és egyszerű alkalmazásokban használjuk.

Másrészt nem kényelmes a nagyszabású webalkalmazások számára. A funkciók gyakran megismétlődnek a JSP-kben, ahol az üzleti és a prezentációs logika összekapcsolódik.

A 2. modell a Model View Controller tervezési mintáján alapul, és elválasztja a nézetet a tartalmat manipuláló logikától.

Ezenkívül három modult különböztethetünk meg az MVC mintában: a modellt, a nézetet és a vezérlőt. A modell az alkalmazás dinamikus adatszerkezetét reprezentálja. Felelős az adatok és az üzleti logika manipulálásáért. A nézet feladata az adatok megjelenítése, míg a vezérlő interfészként szolgál az előző kettő között.

A 2. modellben egy kérést továbbítanak a vezérlőhöz, amely kezeli a szükséges logikát a megjelenítendő megfelelő tartalom megszerzése érdekében. A vezérlő ezután visszahelyezi a tartalmat a kérésbe, általában JavaBean vagy POJO néven. Ezenkívül eldönti, hogy mely nézetben jelenjen meg a tartalom, és végül továbbítja a kérést. Ezután a nézet rendereli az adatokat:

3. Haladó tavaszi MVC kérdések

Q18. Mi a különbség @Vezérlő, @Összetevő, @Repository, és @Szolgáltatás Kommentárok tavasszal?

A hivatalos tavaszi dokumentáció szerint @Összetevő egy általános sztereotípia minden Spring által kezelt komponenshez. @Raktár, @Szolgáltatás, és @Vezérlő szakterületei @Összetevő specifikusabb felhasználási esetek esetén, például a perzisztencia, a szolgáltatás és a bemutatás rétegekben.

Vessünk egy pillantást az utóbbi három konkrét felhasználási esetére:

• @Vezérlő - jelzi, hogy az osztály a kontroller szerepét tölti be, és észleli @RequestMapping osztályon belüli kommentárok
• @Szolgáltatás - azt jelzi, hogy az osztály üzleti logikát és hívási módszereket tartalmaz az adattár rétegben
• @Adattár - azt jelzi, hogy az osztály meghatároz egy adattárat; feladata a platform-specifikus kivételek felzárkóztatása és újbóli bedobása Spring egyik nem ellenőrzött kivételének

Q19. Mik DispatcherServlet és ContextLoaderListener?

Egyszerűen fogalmazva, az elülső vezérlő tervezési mintázatában egyetlen vezérlő felelős a bejövő adatok irányításáért HttpRequests az alkalmazás összes többi vezérlőjéhez és kezelőjéhez.

Tavaszi DispatcherServlet végrehajtja ezt a mintát, ezért felelős a megfelelő koordinálásáért HttpRequests a jobb kezelőknek.

Másrészről, ContextLoaderListener elindul és leállítja Spring gyökerét WebApplicationContext. Összeköti az életciklusát ApplicationContext életciklusához ServletContext. Használhatjuk a különböző tavaszi kontextusokban működő megosztott bab meghatározására.

További részletek a DispatcherServlet, kérjük, olvassa el ezt az oktatóanyagot.

Q20. Mi az a MultipartResolver és mikor használjuk?

A MultipartResolver interfész a fájlok feltöltésére szolgál. A tavaszi keret biztosítja MultipartResolver megvalósítás a Commons FileUpload és egy másik a Servlet 3.0 többrészes kérelem elemzéséhez használható.

Ezek használatával támogathatjuk a fájlfeltöltéseket webalkalmazásainkban.

Q21. Mi az a tavaszi MVC interceptor és hogyan kell használni?

A tavaszi MVC interceptorok lehetővé teszik számunkra, hogy elfogjuk az ügyfél kérését és három helyen dolgozzuk fel - a kérelem kezelése előtt, kezelése után vagy a kérelem teljesítése után (amikor a nézet megjelenik).

Az elfogó használható keresztmetszeti problémákra és az ismétlődő kezelői kód elkerülésére, mint például naplózás, a globálisan használt paraméterek megváltoztatása a Spring modellben stb.

Részletek és különféle megvalósítások a Bevezetés a Spring MVC HandlerInterceptor cikkbe.

Q22. Mi az az Init kötőanyag?

A módszerrel annotált módszer @InitBinder a kérelem paraméterének, az URI sablonnak és a háttér / parancs objektumok testreszabására szolgál. Meghatározzuk egy vezérlőben, és segít a kérés ellenőrzésében. Ebben a módszerben regisztráljuk és konfiguráljuk a szokásainkat PropertyEditors, formázó és validátorok.

A felirat „érték’Elem. Ha nem állítjuk be, akkor a @InitBinder a jegyzetekkel ellátott metódusokat minden HTTP-kérésre meghívják. Ha beállítjuk az értéket, akkor a módszereket csak azokra a parancs / űrlapattribútumokra és / vagy kérési paraméterekre alkalmazzuk, amelyek neve megfelel aérték’Elem.

Fontos megjegyezni, hogy az egyik érvnek meg kell felelnie WebDataBinder. Egyéb argumentumok bármilyen típusúak lehetnek, amelyeket a kezelő metódusai támogatnak, kivéve a parancs / űrlap objektumokat és a megfelelő érvényesítési eredmény objektumokat.

Q23. Magyarázzon el egy kontroller tanácsot

A @ControllerAdvice az annotáció lehetővé teszi számunkra, hogy a vezérlők széles körére alkalmazható globális kódot írjunk. A vezérlők körét egy kiválasztott csomaghoz vagy egy adott kommentárhoz köthetjük.

Alapértelmezés szerint, @ControllerAdvice -val kommentált osztályokra vonatkozik @Vezérlő (vagy @RestController). Van néhány olyan tulajdonságunk is, amelyeket használunk, ha konkrétabbak akarunk lenni.

Ha az alkalmazható osztályokat egy csomagra akarjuk szűkíteni, akkor a csomag nevét hozzá kell adnunk a jegyzethez:

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

Lehetőség van több csomag használatára is, de ezúttal egy tömböt kell használnunk a Húr.

Amellett, hogy a csomagra korlátozzuk a nevét, megtehetjük a csomag egyik osztályának vagy felületének használatával is:

@ControllerAdvice (basePackageClasses = MyClass.class)

A 'attribableTypes’Elem alkalmazza a @ControllerAdvice az adott osztályoknak, mígannotációk„Bizonyos megjegyzésekhez teszi.

Figyelemre méltó emlékezni arra, hogy együtt kell használnunk @ExceptionHandler. Ez a kombináció lehetővé teszi számunkra, hogy globális és specifikusabb hibakezelési mechanizmust állítsunk be, anélkül, hogy minden vezérlőosztály esetében minden egyes megvalósításra szükség lenne.

Q24. Mit csinál a @ExceptionHandler Annotation Do?

A @ExceptionHandler az annotáció lehetővé teszi, hogy meghatározzunk egy módszert, amely a kivételeket kezeli. Lehet, hogy önállóan is használjuk a feliratozást, de sokkal jobb lehetőség a @ControllerAdvice. Így létrehozhatunk egy globális hibakezelési mechanizmust. Ily módon nem kell minden vezérlőn belül megírnunk a kivételkezelés kódját.

Vessen egy pillantást a REST rugóval történő hibakezelésről szóló cikkünkre:

A @ControllerAdvice nyilvános osztály RestResponseEntityExceptionHandler kiterjeszti a ResponseEntityExceptionHandler {@ExceptionHandler (érték = {IllegalArgumentException.class, IllegalStateException.class}) védett ResponseEntity handleConflict = Requestest StructureCommerce kérelem return handleExceptionInternal (ex, bodyOfResponse, új HttpHeaders (), HttpStatus.CONFLICT, kérés); }}

Azt is meg kell jegyeznünk, hogy ez biztosítja @ExceptionHandler módszereket az összes dobó vezérlőnek IllegalArgumentException vagy IllegalStateException. A - vel deklarált kivételek @ExceptionHandler meg kell egyeznie a metódus argumentumaként használt kivétellel. Ellenkező esetben a kivételmegoldó mechanizmus futás közben nem fog működni.

Itt egy dolgot érdemes szem előtt tartani, hogy több is definiálható @ExceptionHandler ugyanarra a kivételre. Nem csinálhatjuk ugyanabban az osztályban, mivel Spring azzal panaszkodna, hogy kivételt dob, és kudarcot vall az indításkor.

Másrészről, ha két külön osztályban definiáljuk ezeket, akkor az alkalmazás elindul, de az első megtalált kezelőt fogja használni, esetleg rosszat.

Q25. Kivételek kezelése a webalkalmazásokban

Három lehetőségünk van a kivételek kezelésére a tavaszi MVC-ben:

• kivételenként
• vezérlőnként
• globálisan

Ha a webkérelem feldolgozása során kezeletlen kivétel merül fel, a kiszolgáló HTTP 500 választ küld vissza. Ennek megakadályozása érdekében meg kell jegyeznünk bármelyik kivételünket a @ResponseStatus annotáció. Az ilyen jellegű kivételeket megoldja HandlerExceptionResolver.

Ez arra készteti a kiszolgálót, hogy a megadott állapotkóddal megfelelő HTTP-választ adjon vissza, amikor egy vezérlő metódusa kiveti a kivételünket. Nem szabad megfeledkeznünk arról, hogy nem kellene valahol máshol kezelnünk a kivételünket, hogy ez a megközelítés működőképes legyen.

A kivételek kezelésének másik módja a @ExceptionHandler annotáció. Hozzátesszük @ExceptionHandler metódusokat bármely vezérlőhöz, és használja azokat a vezérlő belsejéből dobott kivételek kezelésére. Ezek a módszerek képesek kezelni a kivételeket a @ResponseStatus kommentárral, irányítsa át a felhasználót egy dedikált hibanézetre, vagy hozzon létre egy teljesen egyedi hibaválaszt.

A szervlethez kapcsolódó objektumokat is átadhatjuk (HttpServletRequest, HttpServletResponse, HttpSession, és Fő) mint a kezelő módszerek paraméterei. De emlékeznünk kell arra, hogy nem tudjuk betenni a Modell objektumot közvetlenül paraméterként.

A harmadik lehetőség a hibák kezelésére: @ControllerAdvice osztályok. Ez lehetővé teszi számunkra, hogy ugyanazokat a technikákat alkalmazzuk, csak ezúttal az alkalmazás szintjén, és nem csak az adott vezérlőre. Ennek engedélyezéséhez a @ControllerAdvice és a @ExceptionHandler együtt. Így a kivételkezelők kezelik a vezérlők által dobott kivételeket.

Ha részletesebb információt szeretne kapni erről a témáról, olvassa el a REST with Spring hibaelhárítási cikkét.

4. Következtetés

Ebben a cikkben megvizsgáltunk néhány, a Spring MVC-hez kapcsolódó kérdést, amelyek felmerülhetnek a Spring fejlesztők számára készített technikai interjún. Ezeket a kérdéseket vegye figyelembe a további kutatások kiindulópontjaként, mivel ez korántsem teljes körű felsorolás.

Sok sikert kívánunk a közelgő interjúkhoz!