Felületvezérelt vezérlők tavasszal

1. Bemutatkozás

Ebben az oktatóanyagban a Spring MVC új funkcióját vesszük figyelembe, amely lehetővé teszi számunkra, hogy a webes kéréseket a szokásos Java interfészek segítségével adjuk meg.

2. Áttekintés

Általában egy kontroller definiálásakor a Spring MVC-ben metódusait különféle annotációkkal díszítjük, amelyek meghatározzák a kérést: a végpont URL-je, a HTTP kérési módszer, az útváltozók stb.

Bemutathatjuk például a / save / {id} az említett kommentárokat egy egyébként egyszerű módszerrel használó végpont:

@PostMapping ("/ save / {id}") @ResponseBody public Book save (@RequestBody Book book, @PathVariable int id) {// implementáció}

Természetesen ez egyáltalán nem jelent problémát, ha csak egy vezérlőnk van, amely kezeli a kéréseket. A helyzet kissé megváltozik, ha különböző vezérlőkkel rendelkezünk ugyanazokkal a módszeraláírásokkal.

Például a vezérlőnek két különböző verziója lehet - az áttelepítés vagy hasonló okok miatt -, amelyek ugyanazokkal a módszeraláírásokkal rendelkeznek. Ebben az esetben jelentős mennyiségű duplikált jegyzetünk lenne, amelyek a módszer definícióit kísérik. Nyilvánvalóan megsértené a DRY-t (ne ismételje meg magát) elv.

Ha ez a helyzet a tiszta Java osztályok esetében fordul elő, akkor egyszerűen meg kell határoznunk egy felületet, és az osztályokat meg kell valósítanunk. A vezérlőkben a módszerek fő terhe nem a módszer aláírásokból, hanem a módszer annotációiból fakad.

Az 5.1 tavasz azonban új funkciót vezetett be:

A vezérlőparaméter-jelölések az interfészeken is észlelhetők: A teljes leképezési szerződések engedélyezése a vezérlőinterfészekben.

Vizsgáljuk meg, hogyan használhatjuk ezt a funkciót.

3. Vezérlő interfész

3.1. Kontextus beállítása

Az új funkciót egy nagyon egyszerű, a könyveket kezelő REST alkalmazás példáján mutatjuk be. Csak egy vezérlőből áll, olyan módszerekkel, amelyek lehetővé teszik számunkra a könyvek lekérését és módosítását.

Az oktatóanyagban csak a szolgáltatással kapcsolatos kérdésekre koncentrálunk. Az alkalmazás összes megvalósítási kérdése megtalálható a GitHub adattárunkban.

3.2. Felület

Határozzunk meg egy szokásos Java felületet, amelyben nemcsak a módszerek aláírását, hanem a webkérelmek típusát is meghatározzuk:

@RequestMapping ("/ default") nyilvános felület BookOperations {@GetMapping ("/") list getAll (); @GetMapping ("/ {id}") Opcionális getById (@PathVariable int id); @PostMapping ("/ save / {id}") public void save (@RequestBody Book book, @PathVariable int id); }

Figyelje meg, hogy rendelkezhetünk osztályszintű és metódusszintű kommentárokkal is. Most létrehozhatunk egy vezérlőt, amely megvalósítja ezt az interfészt:

@RestController @RequestMapping ("/ book") public class A BookController a BookOperations megvalósítását végzi , int id) {...}}

Ennek ellenére hozzá kell adnunk az osztályszintű kommentárokat @RestController vagy @Vezérlő vezérlőnknek. Az ilyen módon definiálva a vezérlő örököl minden, a webes kérések leképezésével kapcsolatos feljegyzést.

Annak ellenőrzésére, hogy a vezérlő most a várt módon működik-e, futtassuk az alkalmazást, és nyomjuk meg a getAll () módszer a megfelelő kérés benyújtásával:

göndör // helyi házigazda: 8081 / könyv /

Annak ellenére, hogy a vezérlő megvalósítja az interfészt, tovább finomíthatjuk webkérés-megjegyzések hozzáadásával. Megtehetjük ezt oly módon, ahogy az interfészhez tettük: akár osztályszintű, akár metódusszinten. Valójában ezt a lehetőséget használtuk a vezérlő definiálásakor:

A @RequestMapping ("/ book") nyilvános osztályú BookController végrehajtja a BookOperations {...}

Ha webkérés-jelöléseket adunk a vezérlőhöz, azok elsőbbséget élveznek a felületénél. Más szavakkal, Spring a vezérlő interfészeit hasonló módon értelmezi, mint ahogy a Java foglalkozik az örökléssel.

A felületen meghatározzuk az összes általános webkérés tulajdonságot, de a vezérlőben mindig finomhangolhatjuk őket.

3.3. Vigyázat!

Ha van interfészünk és különböző vezérlők, amelyek megvalósítják, akkor olyan helyzetbe kerülhetünk, amikor a webes kéréseket egynél több módszerrel kezelhetjük. Természetesen a Tavasz kivételt hoz:

Okozta: java.lang.IllegalStateException: Kétértelmű feltérképezés.

Ha azzal díszítjük a vezérlőt @RequestMapping, csökkenthetjük a kétértelmű feltérképezések kockázatát.

4. Következtetés

Ebben az oktatóanyagban megvizsgáltuk az 5.1 tavasszal bevezetett új funkciót. Amikor a Spring MVC vezérlők implementálnak egy interfészt, ezt nem csak a szokásos Java módon teszik meg, hanem öröklik az interfészben definiált összes webkéréssel kapcsolatos funkciót is.

Mint mindig, a megfelelő kódrészleteket megtalálhatjuk a GitHub-adattárunkban.


$config[zx-auto] not found$config[zx-overlay] not found