חלק 7. היכרות עם דפוס ה-MVC (Model-View-Controller).

חומר זה הוא חלק מסדרת "מבוא לפיתוח ארגוני". מאמרים קודמים:

• על נטוורקינג
• על ארכיטקטורת תוכנה
• לגבי HTTP/HTTPS
• על היסודות של Maven
• על servlets (כתיבת יישום אינטרנט פשוט)
• לגבי מיכלי servlet

במאמר זה נכיר משהו שנקרא MVC. נדבר על מה זה MVC, ניגע בהיסטוריה שלו, נחקור את הרעיונות והמושגים הבסיסיים הגלומים ב-MVC, נסתכל צעד אחר צעד כיצד לפצל יישום למודול מודל, תצוגה ובקר, נכתוב יישום אינטרנט קטן המשתמש ב-Spring Boot, ובאמצעות Spring MVC כדוגמה, ראה כיצד נתונים נשלחים מקוד Java לדפי HTML. כדי להבין את החומר הזה, אתה צריך להכיר דפוסי עיצוב, במיוחד צופה וחזית. ולהכיר בקשות ותגובות HTTP, להבין את היסודות של HTML ולדעת מהן הערות Java. קח כוס קפה וחטיף, ותרגיש בנוח. בואו נתחיל.

היסטוריה של MVC

הרעיונות מאחורי MVC גובשו על ידי Trygve Reenskaug בזמן שעבד ב-Xerox PARC בסוף שנות ה-70. באותם ימים, העבודה עם מחשבים דרשה תואר ולימוד מתמיד של תיעוד רב היקף. המשימה שפתרה Reenskaug יחד עם קבוצה של מפתחים חזקים מאוד הייתה לפשט את האינטראקציה של משתמש רגיל עם המחשב. היה צורך ליצור כלים שמצד אחד יהיו פשוטים ומובנים ביותר ומצד שני יאפשרו לשלוט במחשבים ובאפליקציות מורכבות. Reenskaug עבד בצוות שפיתח מחשב נייד "לילדי כל הגילאים" - ה-Dynabook, כמו גם שפת SmallTalk בהנהגתו של אלן קיי. אז נקבעו המושגים של ממשק ידידותי. במובנים רבים, העבודה שנעשתה על ידי רינסקאוג והצוות שלו השפיעה על האבולוציה של תחום ה-IT. הנה עובדה מעניינת שאינה חלה ישירות על MVC, אך ממחישה את המשמעות של ההתפתחויות הללו. אלן קיי אמר , "כשהגעתי לראשונה לאפל, שהיה בשנת 84', ה-Mac כבר יצא וניוזוויק יצר איתי קשר ושאל אותי מה אני חושב על המק. אמרתי, 'ובכן, ה-Mac הוא המחשב האישי הראשון מספיק טוב כדי לקבל ביקורת'. אז, לאחר שהכריז על האייפון ב-2007, הוא הביא אותו אליי והושיט לי אותו. הוא אמר, 'אלן, האם זה מספיק טוב כדי לקבל ביקורת?' ואמרתי, 'סטיב, תעשה אותו בגודל כזה גדול כמו טאבלט ואתה תשלוט בעולם'." לאחר 3 שנים, ב-27 בינואר 2010, הציגה אפל את האייפד באלכסון של 9.7 אינץ'. במילים אחרות, סטיב ג'ובס עקב כמעט בדיוק אחר עצתו של אלן קיי. הפרויקט של ריינסקאוג נמשך 10 שנים. אבל הפרסום הראשון על MVC יצא לאור לאחר 10 שנים נוספות. מרטין פאולר, מחברם של מספר ספרים ומאמרים על ארכיטקטורת תוכנה, מזכיר שהוא למד MVC באמצעות גרסת עבודה של Smalltalk. מכיוון שלא היה מידע על MVC מהמקור המקורי במשך זמן רב, ומכמה סיבות אחרות, הופיעו מספר רב של פרשנויות שונות למושג זה. כתוצאה מכך, רבים מחשיבים את MVC כתבנית עיצובית. פחות נפוץ, MVC נקרא דפוס מורכב או שילוב של מספר דפוסים הפועלים יחד ליצירת יישומים מורכבים. אבל, כפי שהוזכר קודם לכן, MVC הוא למעשה אוסף של רעיונות/עקרונות/גישות ארכיטקטוניות שניתן ליישם בדרכים שונות תוך שימוש בדפוסים שונים... לאחר מכן, נשקול את הרעיונות העיקריים המוטמעים בתפיסת ה-MVC.

MVC: רעיונות ועקרונות בסיסיים

• VC הוא אוסף של רעיונות ועקרונות אדריכליים לבניית מערכות מידע מורכבות עם ממשק משתמש
• MVC הוא קיצור המייצג: Model-View-Controller

כתב ויתור: MVC אינו דפוס עיצובי. MVC הוא אוסף של רעיונות ועקרונות אדריכליים לבניית מערכות מורכבות עם ממשק משתמש. אבל מטעמי נוחות, כדי לא לומר שוב ושוב "סט של רעיונות אדריכליים...", נתייחס לתבנית MVC. נתחיל מהפשוט. מה מסתתר מאחורי המילים Model-View-Controller? בעת שימוש בתבנית MVC לפיתוח מערכות עם ממשק משתמש, עליך לחלק את המערכת לשלושה רכיבים. הם יכולים להיקרא גם מודולים או רכיבים. תקראו להם איך שתרצו, אבל חלקו את המערכת לשלושה מרכיבים. לכל רכיב יש מטרה משלו. דֶגֶם. הרכיב/מודול הראשון נקרא המודל. הוא מכיל את כל ההיגיון העסקי של האפליקציה. נוף. החלק השני של המערכת הוא הנוף. מודול זה אחראי על הצגת הנתונים למשתמש. כל מה שהמשתמש רואה נוצר על ידי התצוגה. בקר. החוליה השלישית בשרשרת זו היא הבקר. הוא מכיל את הקוד שאחראי לטיפול בפעולות המשתמש (כל פעולות המשתמש מטופלות בבקר). המודל הוא החלק העצמאי ביותר של המערכת. כל כך עצמאי שאסור לו לדעת דבר על מודולי התצוגה והבקר. המודל כל כך עצמאי עד שהמפתחים שלו לא יודעים כמעט כלום על התצוגה והבקר. המטרה העיקרית של התצוגה היא לספק מידע מהמודל בפורמט שהמשתמש יכול לצרוך. המגבלה העיקרית של ההשקפה היא שאסור לה לשנות את המודל בשום צורה. המטרה העיקרית של הבקר היא לטפל בפעולות המשתמש. באמצעות הבקר המשתמש מבצע שינויים במודל. או ליתר דיוק, לנתונים שמאוחסנים במודל. להלן הדיאגרמה שראית בעבר בשיעור: מכל זה נוכל להסיק מסקנה הגיונית. יש לחלק מערכת מורכבת למודולים. נתאר בקצרה את השלבים להשגת הפרדה זו.

שלב 1. הפרד את ההיגיון העסקי של האפליקציה מממשק המשתמש

הרעיון המרכזי של MVC הוא שניתן לחלק כל אפליקציה עם ממשק משתמש ל-2 מודולים: מודול האחראי על יישום ההיגיון העסקי, וממשק המשתמש. המודול הראשון יישם את הפונקציונליות העיקרית של האפליקציה. מודול זה הוא הליבה של המערכת, שבה מיושם מודל התחום של האפליקציה. בפרדיגמת MVC, מודול זה הוא האות M, כלומר המודל. המודול השני מיישם את כל ממשק המשתמש, כולל ההיגיון להצגת נתונים למשתמש ולטפל באינטראקציה של המשתמש עם האפליקציה. המטרה העיקרית של הפרדה זו היא להבטיח שאת ליבת המערכת ("המודל" בטרמינולוגיה של MVC) ניתן לפתח ולבדוק באופן עצמאי. לאחר ביצוע הפרדה זו, ארכיטקטורת היישום נראית כך:

שלב 2 השתמש בדפוס הצופה כדי להפוך את המודל לעצמאי עוד יותר ולסנכרן ממשקי משתמש

יש לנו 2 מטרות:

1. השג עוד יותר עצמאות עבור המודל
2. סנכרון ממשקי משתמש

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

שלב 3 הפרד את הממשק לתצוגה ולבקר

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

• פלט והצגת מידע מערכת למשתמש בצורה נוחה
• הזן נתוני משתמש ופקודות (תעביר אותם למערכת)

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

1. על פי עקרונות פרדיגמת ה-MVC, יש לחלק מערכת למודולים.
2. המודול החשוב והעצמאי ביותר צריך להיות המודל.
3. המודל הוא הליבה של המערכת. צריך להיות אפשרי לפתח ולבדוק אותו באופן עצמאי מממשק המשתמש.
4. כדי להשיג זאת, בשלב הראשון של החלוקה, עלינו לפצל את המערכת למודל וממשק משתמש.
5. לאחר מכן, באמצעות דפוס הצופה, אנו מחזקים את עצמאות המודל ומסנכרנים ממשקי משתמש.
6. השלב השלישי הוא חלוקת ממשק המשתמש לבקר ותצוגה.
7. כל מה שנדרש כדי לקבל נתוני משתמש למערכת נמצא בבקר.
8. כל מה שנדרש להעברת מידע למשתמש נמצא בתצוגה.

רק עוד דבר חשוב לדון בו לפני שתוכל לשתות את השוקו החם שלך.

קצת על האופן שבו התצוגה והבקר מתקשרים עם הדגם

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

MVC: מה אנחנו מרוויחים?

המטרה העיקרית של פרדיגמת ה-MVC היא להפריד בין יישום ההיגיון העסקי (המודל) לבין ההדמיה שלו (התצוגה). הפרדה זו מגדילה את האפשרויות לשימוש חוזר בקוד. היתרונות של MVC ניכרים ביותר כאשר אנו צריכים להציג את אותם נתונים בפורמטים שונים. לדוגמה, כטבלה, גרף או תרשים (באמצעות תצוגות שונות). יחד עם זאת, מבלי להשפיע על אופן הטמעת התצוגות, אנו יכולים לשנות את האופן שבו אנו מגיבים לפעולות המשתמש (לחיצות על כפתורים, הזנת נתונים). אם תפעל לפי העקרונות של MVC, תוכל לפשט את פיתוח התוכנה, להגביר את קריאת הקוד ולשפר את יכולת ההרחבה והתחזוקה. במאמר האחרון בסדרת "מבוא לפיתוח ארגוני", נתבונן ביישום MVC שנבנה באמצעות Spring MVC. חלק 8. בואו נכתוב אפליקציה קטנה באמצעות Spring Boot