אסטרטגיות טעינת המידע
של Entity Framework Core
join. מתאים כשיודעים מראש שצריך את כל המידע, למשל השוואה בין סוגי פידג'ט ספינר שבה המשתמשים בודקים פרטים נוספים כמו מחירים וקבוצות גיל.פרקי ההרצאה: אסטרטגיות טעינת המידע של Entity Framework Core
תמלול ההרצאה: אסטרטגיות טעינת המידע של Entity Framework Core
הטקסט המלא של הדקות הראשונות בהרצאה «אסטרטגיות טעינת המידע של Entity Framework Core» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
אנחנו מגיעים לנושא מאוד מעניין שנקרא לואודינג סטרטג'יז, אסטרטגיות טעינה. קודם כל, בואו נבין איזשהו סנאריו, איזשהו תרחיש מסוים שהרבה פעמים קורה. יש לנו את טבלת המתנות, יש לנו את השם של המתנה, את המחיר, יש לנו את הקוד שלה, ואנחנו רוצים להביא מתנות ולהציג מתנות, זה בעצם הדבר המרכזי שאנחנו מתעסקים איתו.
אז ברור שאנחנו רוצים להציג את השם של המתנה וגם את המחיר אבל אנחנו לא באמת רוצים להציג את הקוד של קבוצת הגיל שלה הרי היוזר לא אמור לראות קודים זה לא מעניין אותו שקבוצת הגיל יש לה קוד אחד אז ברור שיש לנו פה גם את הטבלה השנייה של קבוצות גילאים יש לנו h group ID שזה הקוד של קבוצת גיל ולכן יש פה את הטבלה בטבלת המתנות את קוד
קבוצת הגיל וכמובן בדאטאבייס יש יש ריליישן ביניהם. אנחנו רוצים להציג את המתנות, זה המידע המרכזי שלנו, אבל אנחנו רוצים עבור כל מתנה להציג גם מה השם הזה של קבוצת הגיל, ש-cute doll, עבור babies ולא עבור children.
בואו לצורך הדוגמה הזאת נקרא למידע הזה Main Data, אפשר לקרוא לו גם Primary Data, המידע המרכזי שאנחנו רוצים להציג, הטבלה הראשית שלנו.
ולמידע הזה בואו נקרא סקנדרי דאטה או אפשר לקרוא לו רילייטד דאטה גם כן סקנדרי טייבל הטבלה המשנית המידע הנלווה יש לזה בעצם כל מיני שמות אנחנו רוצים להציג למשתמש גם את זה וגם את השם של אותה מתנה בסדר גמור אנחנו יודעים ששפת sql יודעת לבצע את זה כמובן גם entity framework יודעת לבצע את זה אבל בואו רגע נחשוב טוב, האם כדאי איך שהאפליקציה עולה להביא
את כל המידע הראשי וגם את המידע המשני? רגע, אולי היוזר לא תמיד רוצה לראות את המידע המשני, אולי הוא רוצה לראות את המידע המשני רק אם הוא לוחץ על איזשהו more details, מידע נוסף או משהו כזה.
למה בעצם לא להביא את כל המידע? מה אכפת לנו? יש לנו פה תמיד צורך באיזון בין performance, המהירות, לבין memory, אם אנחנו אומרים תביא לי את הכל כולל הכל אז הוא מביא לי את כל המידע זה כמובן המון המון בזבוז של זיכרון.
אם אני אומר תביא לי את המידע הרבה פעמים אבל רק כשאני צריך אותו אז יש לנו פה המון פניות לדאטאבייס ואנחנו צריכים להביא נקודה חשובה כל פנייה לדאטאבייס זה משהו שגוזל זמן פניות לדאטאבייס נחשבות איטיות מבחינת המערכת כשאנחנו פונים לדאטאבייס הדאטאבייס יוצר בשבילנו משהו שנקרא סשן שמלווה את הפנייה ומשרת אותה.
ומקבל את השאילתה ומפרש אותה ומביא לנו את המידע ושומר כל מיני דברים לאיזשהו לוג שלו. זאת אומרת, יש פה המון פעולות שהדאטאבייס עושה עבור כל פנייה.
אז פניות נחשבות משהו איטי ואנחנו רוצים לחסוך בפניות לדאטאבייס. אז אנחנו צריכים פה לאזן בין כמות הפניות לדאטאבייס ובין הזיכרון שאנחנו מביאים.
כי להביא את הכל הכל הכל בבת אחת, אולי זה לא נדרש, אפילו שזה יהיה שאילתה אחת. לצורך כך, אנטיטי פריימוורק מציגה לנו את מה שנקרא אסטרטגיות תאנה לואודינג סטרטג'יז.
אז בואו נעבור ונראה מהם האסטרטגיות תאנה שאנטיטי פריימוורק נותנת לנו. אז קודם כל מה זה? אסטרטגיות תאנה זה הטכניקות השונות שמאפשרות להביא את אותו מידע נלווה, את אותו מידע משני מהדאטאבייס.
אסטרטגיות האלה מאפשרות למתכנתים לעשות את אותו איזון בין הפרפורמנס, המהירות, לבין הזיכרון לפי הצרכים של האפליקציה. מה בעצם אנחנו רוצים ספציפית לגבי הלוגיקה שלנו.
יש שלוש אסטרטגיות תאנה. Lazy loading, כאשר lazy זה עצלן. Explicit loading, כאשר explicit זה מפורש. ו-Eager loading, כאשר Eager זה נלהב. בואו נראה מה זה Lazy loading ראשית.
אז Lazy loading זו אותה טכניקה שאוטומטית מביאה את המידע הנלווה, המידע המשני, כאשר אנחנו רק ניגשים אליו, נניח אני רוצה רק להציג אותו. אני מציג את השם של קבוצת הגיל, בום, המערכת הולכת, מביאה את המידע הזה מהדאטאבייס.
הוא לא מביא את המידע בעלייה הראשונית או בשאילתה הראשונית של המידע הראשי. כמובן שזה יכול ליצור המון פניות לדאטאבייס, יכול להיות שאנחנו רצים באיזושהי לולאה וכל פעם אומרים, תציג לי גם את השם של קבוצת הגיל, תציג לי גם את השם, מציג לי גם את השם המון המון פעמים בלולאה, כל פעם יכולה להיות פנייה לדאטאבייס, זה כמובן
יכול להיות מאוד לא יעיל. אז מתי זה מתאים? זה מתאים כאשר אנחנו יודעים שלעיתים נדירות המשתמש בעצם רוצה לראות את אותו מידע משני, אז אולי לא כדאי להביא אותו בכלל בטעינה הראשונית, אלא אם צריך לך ותביא אוטומטית.
בואו נראה use case, דוגמה למצב הזה. אנחנו מציגים תיבת חיפוש של מתנות ומציגים רשימה של הרבה מתנות. אנחנו שמים לב שכשהיוזר רואה רשימת מתנות לפי מה שהוא חיפש, אז נדיר שהוא נכנס בשביל לראות מידע נלווה לכל מתנה, מידע משני עבור מתנה.
לכן אנחנו אומרים, תשמע, תביא לי את התוצאות חיפוש של המתנות, אבל תביא לי רק את המתנות. אל תביא לי מידע נלווה של למי שייכת אותה מתנה, לאיזה קבוצות גיל. אם היוזר ירצה וייכנס לתוצאת חיפוש, אז לך ותביא אוטומטית lazy, אל תביא ישר, תביא אוטומטית כשאנחנו נכנסים ומציגים את זה.
אם אנחנו מסתכלים על הסכמה יש לנו פה את המתנות ואת קבוצות הגיל, יש לנו את האפליקציה. קודם כל מה שאנחנו עושים זה בכל מקרה מביאים את המידע הראשי, ברור, אני מביא את התוצאות חיפוש של המתנות.
אנחנו לא מביאים שום דבר שקשור לקבוצות גיל, לא את השמות, לא כלום. יוזר לוחץ על איזשהו תוצאת חיפוש, אוקיי, אז אוטומטית המערכת אומרת, אה, אתה צריך לראות גם את השם של קבוצת הגיל?
שום בעיה, אני הולכת לדאטאבייס ומביאה את השם של קבוצת הגיל. יוזר מקליק על מתנה נוספת כי הוא רוצה לראות את הפרטים, שום בעיה, נלך ונביא גם אותה.
בסדר, כי היוזר רצה, וזאת תהיה פנייה נוספת.