streamalism.org

1. Áttekintés

Ebben a gyors bemutatóban a különbségekre fogunk összpontosítani @Érvényes és @Validated annotációk tavasszal.

A felhasználók bevitelének ellenőrzése a legtöbb alkalmazásunkban általános funkció. A Java ökoszisztémában ennek támogatására kifejezetten a Java Standard Bean Validation API-t használjuk. Sőt, ez a 4.0-tól kezdve jól integrálható a Spring-be is. A @Érvényes és @Validated a kommentárok ebből a Standard Bean API-ból származnak.

A következő szakaszokban nézzük meg őket részletesen.

2. @Érvényes és @Validated Megjegyzések

Tavasszal a JSR-303-at használjuk @Érvényes jegyzet a metódus szintű validáláshoz. Sőt, azt is használjuk, hogy jelöljük a tag attribútumot az érvényesítéshez. Ez a megjegyzés azonban nem támogatja a csoportellenőrzést.

A csoportok segítenek korlátozni az érvényesítés során alkalmazott korlátozásokat. Az egyik speciális felhasználási eset a felhasználói felület varázslók. Itt az első lépésben rendelkezhetünk egy bizonyos mezők alcsoportjával. A következő lépésben lehet egy másik csoport, amely ugyanahhoz a babhoz tartozik. Ezért korlátozásokat kell alkalmaznunk ezekre a korlátozott mezőkre minden lépésben, de @Érvényes nem támogatja ezt.

Ebben az esetben, csoportszinten a Spring-et kell használnunk @Validated, amely ennek a JSR-303-nak a változata @Érvényes. Ezt a módszer szintjén használják. A tagattribútumok jelöléséhez pedig továbbra is a @Érvényes annotáció.

Most merüljünk bele, és egy példával nézzük meg ezeknek a kommentároknak a használatát.

3. Példa

Vizsgáljuk meg a Spring Boot használatával kifejlesztett egyszerű felhasználói regisztrációs űrlapot. Először is csak a név és a Jelszó attribútumok:

public class UserAccount {@NotNull @Size (min = 4, max = 15) private String jelszó; @NotBlank privát karakterlánc neve; // standard kivitelezők / beállítók / getters / toString} 

Ezután nézzük meg a vezérlőt. Itt lesz saveBasicInfo módszer a @Érvényes kommentár a felhasználói bevitel ellenőrzéséhez:

@RequestMapping (value = "/ saveBasicInfo", method = RequestMethod.POST) public String saveBasicInfo (@Valid @ModelAttribute ("useraccount") UserAccount useraccount, BindingResult result, ModelMap model) {if (result.hasErrors ()) return hiba"; } return "siker"; }

Most teszteljük ezt a módszert:

@Test public void givenSaveBasicInfo_whenCorrectInput_thenSuccess () dobja a Kivételt {this.mockMvc.perform (MockMvcRequestBuilders.post ("/ saveBasicInfo") .accept (MediaType.TEXT_HTML) .param ("név", "test123". "pass")) .andExpect (view (). name ("siker")) .andExpect (status (). isOk ()) .andDo (print ()); }

Miután megerősítettük, hogy a teszt sikeresen fut, bontsuk ki most a funkcionalitást. A következő logikus lépés ennek átalakítása többlépcsős regisztrációs űrlaphoz, ahogyan ez a legtöbb varázsló esetében is történik. Az első lépés a név és a Jelszó változatlanul marad. A második lépésben további információkat szerzünk be, például kor és telefon. Ezért a következő objektumokkal frissítjük a domain objektumunkat:

public class UserAccount {@NotNull @Size (min = 4, max = 15) private String jelszó; @NotBlank privát karakterlánc neve; @Min (érték = 18, üzenet = "Az életkor nem lehet kevesebb 18-nál") private int age; @NotBlank privát String telefon; // standard kivitelezők / beállítók / getters / toString} 

Ezúttal azonban észrevesszük, hogy az előző teszt kudarcot vall. Ez azért van, mert nem adjuk át a kor és telefon mezők, amelyek továbbra sem szerepelnek a felhasználói felületen. A viselkedés támogatásához szükségünk lesz a csoport validálására és a @Validated annotáció.

Ehhez két külön csoportot létrehozva kell csoportosítanunk a mezőket. Először két marker interfészt kell létrehoznunk. Minden csoporthoz vagy lépéshez külön. Ennek pontos megvalósításához hivatkozhatunk a csoportellenőrzésről szóló cikkünkre. Itt összpontosítsunk az annotációk különbségeire.

Megvan a Alapinformáció interfész az első lépéshez és a AdvanceInfo a második lépéshez. Ezenkívül frissítjük a termékeinket Felhasználói fiók osztály használhatja ezeket a marker interfészeket az alábbiak szerint:

public class UserAccount {@NotNull (groups = BasicInfo.class) @Size (min = 4, max = 15, csoportok = BasicInfo.class) privát karakterlánc jelszó; @NotBlank (csoportok = BasicInfo.class) privát karakterlánc neve; @Min (érték = 18, üzenet = "Az életkor nem lehet kevesebb 18-nál", csoportok = AdvanceInfo.class) private int age; @NotBlank (csoportok = AdvanceInfo.class) privát String telefon; // standard kivitelezők / beállítók / getters / toString} 

Ezenkívül frissítjük vezérlőnket a @Validated felirat helyett @Érvényes:

@RequestMapping (value = "/ saveBasicInfoStep1", method = RequestMethod.POST) public String saveBasicInfoStep1 (@Validated (BasicInfo.class) @ModelAttribute ("useraccount") UserAccount useraccount, BindingResult {(resultMap result) (ModelMap result. )) {return "hiba"; } return "siker"; }

A frissítés eredményeként tesztünk sikeresen fut. Most teszteljük ezt az új módszert is:

@Test public void givenSaveBasicInfoStep1_whenCorrectInput_thenSuccess () dobja a Kivételt {this.mockMvc.perform (MockMvcRequestBuilders.post ("/ saveBasicInfoStep1") .accept (MediaType.TEXT_HTML) .param ("név" .param ("név" .param ("név"). "pass")) .andExpect (view (). name ("siker")) .andExpect (status (). isOk ()) .andDo (print ()); }

Ez is sikeresen fut. Ezért láthatjuk, hogyan használata @Validated elengedhetetlen a csoport validálásához.

Ezután nézzük meg, hogyan @Érvényes elengedhetetlen a beágyazott attribútumok érvényesítésének kiváltásához.

4. Használata @Érvényes Megjegyzés a beágyazott objektumok megjelöléséhez

A @Érvényes az annotációt elsősorban a beágyazott attribútumok megjelölésére használják. Ez elindítja a beágyazott objektum érvényesítését. Például a jelenlegi forgatókönyvünkben hozzunk létre egy Felhasználói cím tárgy:

public class UserAddress {@NotBlank private String countryCode; // standard kivitelezők / beállítók / getters / toString}

A beágyazott objektum érvényesítésének biztosítása érdekében az attribútumot a @Érvényes kommentár:

public class UserAccount {// ... @Valid @NotNull (csoportok = AdvanceInfo.class) privát UserAddress felhasználói cím; // standard kivitelezők / beállítók / getters / toString}

5. Érvek és ellenérvek

Nézzük meg a használat néhány előnyét és hátrányát @Érvényes és @Validated annotációk tavasszal.

A @Érvényes az annotáció biztosítja az egész objektum érvényesítését. Fontos, hogy elvégzi a teljes objektumgrafikonok hitelesítését. Ez azonban olyan problémákat vet fel, amelyek csak részleges ellenőrzést igényelnek.

Másrészt használhatjuk @Validated a csoport validálásához, beleértve a fenti részleges érvényesítést is. Ebben az esetben azonban az érvényesített entitásoknak ismerniük kell az összes csoport vagy felhasználási eset validálási szabályait, amelyekben használják. Itt keverjük össze az aggodalmakat, ezért ez antimintát eredményezhet.

6. Következtetés

Ebben a gyors bemutatóban feltártuk a legfontosabb különbségeket @Érvényes és @Validated Megjegyzések.

Következtetésként elmondhatjuk, hogy minden alapvető hitelesítéshez a JSR-t fogjuk használni @Érvényes annotáció a módszerünkben. Másrészről, bármilyen csoportellenőrzéshez, beleértve a csoportos szekvenciákat is, a Spring-et kell használnunk @Validated annotáció a módszerhívásunkban. A @Érvényes annotációra is szükség van a beágyazott tulajdonságok érvényesítésének kiváltásához.

Mint mindig, a cikkben bemutatott kód elérhető a GitHubon.