וולידציה למספר מאפיינים יחד
required לא עוזר כאן, כי הוא דורש תמיד ערך.IValidatableObject: המודל (book) מממש אותו, ו-dotnet קורא לפונקציה Validate שלו כחלק מהוולידציה. היא מחזירה collection של שגיאות, ו-list ריקה אומרת שאין שגיאות. הבדיקה נעשית בתוך המחלקה, ולכן אפשר להשתמש בכל המאפיינים שלה.List<ValidationResult> בשם errors ומחזירים אותה בסוף. רשימה, כי אפשר להחזיר בבת אחת כמה שגיאות מבדיקות שונות.description.Length קטן מ-title.Length, מוסיפים ValidationResult עם ההודעה "description must be longer than title".ValidationResult גם רשימת faultyMembers עם title ו-description.nameof: במקום לכתוב את השם כטקסט משתמשים באופרטור nameof, שמחזיר את שם ה-property. אם משנים אחר כך את השם (למשל ל-bookName ב-rename), הערך מתעדכן אוטומטית.errors כבר Contains את ההודעה.פרקי ההרצאה: וולידציה למספר מאפיינים יחד
תמלול ההרצאה: וולידציה למספר מאפיינים יחד
הטקסט המלא של הדקות הראשונות בהרצאה «וולידציה למספר מאפיינים יחד» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
מה קורה אם אנחנו רוצים לבצע איזושהי בדיקת ולידציה, אבל היא לא שייכת רק למאפיין אחד? היא שייכת בבת אחת לשניים או יותר. יכול להיות מצב שיש לכם אולי, בוא נגיד, אה, איזשהו אובייקט שיש בו טלפון ו-email, ומבחינתכם ח-חייב שיהיה או טלפון או email או שניהם, אבל אסור אף אחד מהם.
אז אם יש לי טלפון ו-email ואני צריך אחד מהם, על מי אני שם את הוולידציה? אני לא יכול לשים required, כי required זה אומר שהוא תמיד תמיד חייב להיות. כן, בואו ניקח את הדוגמה הזאת.
אני רוצה או title או description, נניח כמובן, זה לא המקרה, אבל נניח, אבל אסור שלא יהיה אף אחד מהם. אז required על כל אחד מהם או על שניהם לא פותר לי את הבעיה.
אה, מקרה אחר כזה יכול להיות, יש לי אובייקט שמתאר מוצר ולמוצר יש גם, אה, כמה מזמינים ממנו וגם כמות במלאי, ואסור ש-אאא יביאו לי מוצר שמספר הפריטים שמזמינים ממנו גדול מכמות הפריטים במלאי, ואלה שני מאפיינים שונים לגמרי.
אז אנחנו רוצים עכשיו לבצע איזושהי ולידציה שקשורה למספר מאפיינים שונים, וזה אומר שאני לא באמת יכול לשים אותה על אחד מהם, כי אני צריך להתייחס לשניהם ביחד. אז מה שעושים זה מממשים interface שנקרא IValidatableObject.
בואו נממש אותו, implement, ויש לנו פה את הפונקציה הזאת, וזה interface מאוד פשוט שמה שהוא אומר ל-dot net זה שאם ה-book ירש את ה-interface הזה, אז כחלק מתהליך הוולידציה יש לקרוא גם לפונקציה הזאת, והפונקציה הזאת מחזירה בעצם איזשהו collection שמתאר את השגיאות שהתרחשו, או אם אני מחזיר list ריקה לגמרי, אז אין בכלל שגיאות, ואז אנחנו יכולים לבדוק כאן מה שבא לנו יחסית לאובייקט, מפני שאנחנו נמצאים בתוך המחלקה
עצמה. אז בואו נחליט מה אנחנו בודקים. בואו נניח שאסור שהאורך של ה-title יהיה יותר ארוך מהאורך של ה-description. סתם זרקתי משהו שזה בכלל לא משהו שהייתי בודק אותו בתעשייה, אבל אין לי פה כל כך בשר לעבוד איתו.
אה, אין לי כל כך מה לבדוק. רק לצורך הדוגמה, איך עובדים עם הפונקציה הזאת. נניח שמבחינתנו ה-title חייב להיות... הוא לא יכול להיות יותר ארוך מה-description.
זה גם לא כזה הגיוני, כן? Description צריך להיות ארוך. אוקיי. איך עושים את זה? מכינים קודם כל list מסוג ValidationResult, ובואו נקרא לה errors new, והנה יש לנו את ה-list, ובסוף בסוף מחזירים errors בצורה כזאת.
קודם כל בנינו list ריקה. עכשיו בואו נראה רגע כאן, ב-extra spacing forbidden, היה לנו גם כן ValidationResult, אבל כאן אנחנו בונים list, כי יכול להיות מספר שגיאות ולא אחת שאנחנו יכולים בבת אחת להחזיר.
אז יכול להיות שאנחנו רוצים לבדוק גם את ה-title מול ה-description, גם את ה-email מול הטלפון, גם את זה מול זה, ובבת אחת להחזיר את כל השגיאות, כי יש לנו רק פונקציה אחת כזאת.
אוקיי, אז בואו נבדוק. אם ה-description נקודה length יותר קטן או שווה, נגיד יותר קטן מ-title נקודה length, אז זה מצב שבו יש לנו באמת שגיאה ואנחנו רוצים להחזיר את ה-list, למלא אותה ולהגיד, "בוא בעצם תחזיר לי את השגיאה אחת שמצאנו".
errors נקודה add, ואנחנו רוצים להוסיף אובייקט ValidationResult חדש. אז בואו נפתח כאן ValidationResult. נקרא לו error אחד שווה new