streamalism.org

1. סקירה כללית

במדריך מהיר זה נתמקד בהבדלים בין @תָקֵף ו @ מאושר ביאורים באביב.

אימות קלט המשתמשים הוא פונקציונליות נפוצה ברוב היישומים שלנו. במערכת האקולוגית של ג'אווה, אנו משתמשים באופן ספציפי ב- API Standard Bean Validation API לתמיכה בכך. יתר על כן, זה גם משולב היטב עם אביב מגירסה 4.0 ואילך. ה @תָקֵף ו @ מאושר ההערות נובעות ממשק API זה של שעועית רגילה.

בחלקים הבאים בואו נסתכל עליהם בפירוט.

2. @תָקֵף ו @ מאושר ביאורים

באביב אנו משתמשים ב- JSR-303 @תָקֵף ביאור לאימות ברמת השיטה. יתר על כן, אנו משתמשים בה גם כדי לסמן מאפיין חבר לאימות. עם זאת, הערה זו אינה תומכת באימות קבוצתי.

קבוצות עוזרות להגביל את האילוצים המופעלים במהלך האימות. מקרה שימוש מסוים הוא אשפי ממשק המשתמש. כאן, בשלב הראשון, עשויה להיות לנו תת-קבוצה מסוימת של שדות. בשלב הבא, עשויה להיות קבוצה נוספת השייכת לאותה שעועית. לפיכך עלינו להחיל אילוצים על שדות מוגבלים אלה בכל שלב, אך @תָקֵף לא תומך בזה.

במקרה הזה, ברמה הקבוצתית עלינו להשתמש באביב @ מאושר, שהוא גרסה של JSR-303 זה @תָקֵף. משתמשים בזה ברמת השיטה. ולסימון תכונות חבר, אנו ממשיכים להשתמש ב- @תָקֵף ביאור.

עכשיו, בואו נצלול פנימה ונסתכל על השימוש בהערות אלה בדוגמה.

3. דוגמא

בואו ניקח בחשבון טופס הרשמה פשוט למשתמש שפותח באמצעות Spring Boot. ראשית, יהיה לנו רק את שֵׁם וה סיסמה תכונות:

מחלקה ציבורית UserAccount {@NotNull @Size (min = 4, max = 15) סיסמת מחרוזת פרטית; @NotBlank שם מחרוזת פרטי; // קונסטרוקטורים סטנדרטיים / סטרים / getters / toString} 

לאחר מכן, בואו נסתכל על הבקר. הנה, יהיה לנו את saveBasicInfo שיטה עם @תָקֵף הערה לאימות קלט המשתמש:

@RequestMapping (value = "/ saveBasicInfo", method = RequestMethod.POST) ציבורי מחרוזת saveBasicInfo (@Valid @ModelAttribute ("useraccount") UserAccount useraccount, BindingResult result, ModelMap model) {if (result.hasErrors ()) {return " שְׁגִיאָה"; } להחזיר "הצלחה"; }

עכשיו בואו לבדוק את השיטה הזו:

@Test הציבור בטל שניתןSaveBasicInfo_whenCorrectInput_thenSuccess () זורק חריג {this.mockMvc.perform (MockMvcRequestBuilders.post ("/ saveBasicInfo"). קבלה (MediaType.TEXT_HTML) .param ("שם", "סיסמת test123"). "לעבור")) .andExpect (תצוגה (). שם ("הצלחה")). andExpect (סטטוס (). isOk ()). ועשה (הדפס ()); }

לאחר אישור שהבדיקה פועלת בהצלחה, כעת נרחיב את הפונקציונליות. השלב ההגיוני הבא הוא להמיר זאת לטופס רישום רב-שלבי, כמו שקורה ברוב הקוסמים. הצעד הראשון עם שֵׁם וה סיסמה נותר ללא שינוי. בשלב השני נביא מידע נוסף כמו גיל ו מכשיר טלפון. לפיכך נעדכן את אובייקט התחום שלנו בשדות נוספים אלה:

מחלקה ציבורית UserAccount {@NotNull @Size (min = 4, max = 15) סיסמת מחרוזת פרטית; @NotBlank שם מחרוזת פרטי; @Min (value = 18, message = "הגיל לא צריך להיות פחות מ- 18") גילאי פרטי; טלפון מחרוזת פרטי @NotBlank; // קונסטרוקטורים סטנדרטיים / סטרים / getters / toString} 

עם זאת, הפעם נבחין כי המבחן הקודם נכשל. הסיבה לכך היא שאנחנו לא עוברים ב גיל ו מכשיר טלפון שדות, שעדיין לא נמצאים בתמונה בממשק המשתמש. כדי לתמוך בהתנהגות זו, נצטרך אימות קבוצתי ו- @ מאושר ביאור.

לשם כך, עלינו לקבץ את השדות וליצור שתי קבוצות נפרדות. ראשית, נצטרך ליצור שני ממשקי סמן. קבוצה נפרדת לכל קבוצה או לכל שלב. אנו יכולים להפנות למאמר שלנו בנושא אימות קבוצתי לצורך יישום מדויק של זה. הנה, נתמקד בהבדלים בין ההערות.

יהיה לנו את מידע בסיסי ממשק לצעד הראשון ול- AdvanceInfo לשלב השני. יתר על כן, נעדכן את שלנו חשבון משתמש בכיתה להשתמש בממשקי סמן אלה באופן הבא:

מחלקה ציבורית UserAccount {@NotNull (קבוצות = BasicInfo.class) @Size (min = 4, max = 15, קבוצות = BasicInfo.class) סיסמת מחרוזת פרטית; @NotBlank (קבוצות = BasicInfo.class) שם פרטי מחרוזת; @Min (value = 18, message = "הגיל לא צריך להיות פחות מ 18", קבוצות = AdvanceInfo.class) גילאי פרטי; @NotBlank (קבוצות = AdvanceInfo.class) טלפון מחרוזת פרטי; // קונסטרוקטורים סטנדרטיים / סטרים / getters / toString} 

בנוסף, כעת נעדכן את הבקר שלנו לשימוש ב- @ מאושר ביאור במקום @תָקֵף:

@RequestMapping (value = "/ saveBasicInfoStep1", method = RequestMethod.POST) מחרוזת saveBasicInfoStep1 (@Validated (BasicInfo.class) @ModelAttribute ("useraccount") חשבון משתמש של חשבון משתמש, תוצאת BindingResult, ModelMap מודל) {אם תוצאה. )) {להחזיר "שגיאה"; } להחזיר "הצלחה"; }

כתוצאה מעדכון זה, הבדיקה שלנו פועלת כעת בהצלחה. עכשיו בואו גם לבדוק את השיטה החדשה הזו:

@Test הציבור בטל שניתןSaveBasicInfoStep1_whenCorrectInput_thenSuccess () זורק חריג {this.mockMvc.perform (MockMvcRequestBuilders.post ("/ saveBasicInfoStep1"). קבלה (MediaType.TEXT_HTML). "שם" "". "." "". "." "לעבור")) .andExpect (תצוגה (). שם ("הצלחה")). andExpect (סטטוס (). isOk ()). ועשה (הדפס ()); }

גם זה פועל בהצלחה. מכאן נוכל לראות כיצד השימוש ב @ מאושר חיוני לאימות קבוצתי.

לאחר מכן, בואו נראה איך @תָקֵף חיוני להפעלת אימות תכונות מקוננות.

4. שימוש @תָקֵף ביאור לסימון אובייקטים מקוננים

ה @תָקֵף הערה משמשת לסימון תכונות מקוננות במיוחד. זה מפעיל את האימות של האובייקט המקונן. לדוגמה, בתרחיש הנוכחי שלנו, בואו ניצור UserAddress לְהִתְנַגֵד:

מחלקה ציבורית UserAddress {@NotBlank פרטי מחרוזת countryCode; // קונסטרוקטורים סטנדרטיים / סטרים / getters / toString}

כדי להבטיח אימות של אובייקט מקונן זה, נקשט את התכונה ב- @תָקֵף ביאור:

מחלקה ציבורית UserAccount {// ... @Valid @NotNull (קבוצות = AdvanceInfo.class) כתובת משתמש UserAddress פרטית; // קונסטרוקטורים סטנדרטיים / סטרים / getters / toString}

5. יתרונות וחסרונות

בואו נסתכל על כמה מהיתרונות והחסרונות של השימוש @תָקֵף ו @ מאושר ביאורים באביב.

ה @תָקֵף ביאור מבטיח את אימות האובייקט כולו. חשוב לציין שהוא מבצע אימות של כל גרפי האובייקט. עם זאת, הדבר יוצר בעיות לתרחישים הזקוקים לאימות חלקי בלבד.

מצד שני, אנחנו יכולים להשתמש @ מאושר לאימות קבוצתי, כולל האימות החלקי שלעיל. עם זאת, במקרה זה, הישויות המאומתות צריכות לדעת את כללי האימות עבור כל הקבוצות או מקרי השימוש שבהם משתמשים. כאן אנו מערבבים חששות, ומכאן הדבר יכול לגרום לדפוס אנטי.

6. מסקנה

במדריך מהיר זה בחנו את ההבדלים העיקריים בין @תָקֵף ו @ מאושר ביאורים.

לסיום, עבור כל אימות בסיסי, נשתמש ב- JSR @תָקֵף ביאור בשיחות השיטה שלנו. מצד שני, עבור כל אימות קבוצתי, כולל רצפי קבוצות, נצטרך להשתמש ב- Spring @ מאושר ביאור בשיחת השיטה שלנו. ה @תָקֵף הערה נדרשת גם כדי להפעיל אימות של נכסים מקוננים.

כמו תמיד, הקוד המוצג במאמר זה זמין באתר GitHub.