חלק 7. מבוא לתבנית MVC (Model-View-Controller).

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

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

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

היסטוריה של MVC

הרעיונות ל-MVC גובשו על ידי Trygve Reenskaug בזמן שעבד ב-Xerox PARC בסוף שנות ה-70. באותם ימים, לעבוד עם מחשב אי אפשר היה להסתדר בלי תואר אקדמי ולימוד מתמיד של תיעוד רב עוצמה. הבעיה ש-Reenskaug פתרה יחד עם קבוצה של מפתחים חזקים מאוד הייתה לפשט את האינטראקציה של המשתמש הממוצע עם מחשב. היה צורך ליצור כלים שמצד אחד יהיו פשוטים ומובנים ביותר ומצד שני יאפשרו לנהל מחשב ואפליקציות מורכבות. Reenskaug עבד בצוות שפיתח מחשב נייד "לילדי כל הגילאים" - Dynabook, כמו גם את שפת SmallTalk בהנהגתו של אלן קיי. אז ושם הונחו המושגים של ממשק ידידותי. עבודתו של רינסקאוג עם הצוות שלו השפיעה רבות על התפתחות תחום ה-IT. הבה נציג עובדה מעניינת שאינה קשורה ישירות ל-MVC, אך ממחישה את המשמעות של ההתפתחויות הללו. ב-2007, לאחר הצגת האייפון של אפל, אלן קיי אמר: "כשהמקינטוש יצא, ניוזוויק שאל מה אני חושב עליו. אמרתי: זה המחשב האישי הראשון שראוי לביקורת. לאחר המצגת עלה סטיב ג'ובס ושאל: האם האייפון ראוי לביקורת? ואני אמרתי, תעשה את זה חמישה על שמונה סנטימטרים ותכבוש את העולם." שלוש שנים מאוחר יותר, ב-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, עליך לחלק את המערכת לשלושה רכיבים. אלה, בתורם, יכולים להיקרא מודולים או רכיבים. תגיד מה שאתה רוצה, אבל חלק בשלוש. לכל רכיב תהיה מטרה משלו. דֶגֶם. הרכיב/מודול הראשון הוא מה שנקרא מודל. הוא מכיל את כל ההיגיון העסקי של האפליקציה. נוף. החלק השני של המערכת הוא הנוף. מודול זה אחראי על הצגת הנתונים למשתמש. כל מה שהמשתמש רואה נוצר על ידי התצוגה. בקר. החוליה השלישית בשרשרת זו היא הבקר. הוא מאחסן קוד שאחראי על עיבוד פעולות המשתמש (כל פעולת משתמש במערכת מעובדת בבקר). המודל הוא החלק העצמאי ביותר של המערכת. כל כך עצמאי שהוא לא אמור לדעת כלום על מודולי התצוגה והבקר. המודל כל כך עצמאי עד שהמפתחים שלו לא יודעים כמעט כלום על ה-View והבקר. המטרה העיקרית של התצוגה היא לספק מידע מהמודל בפורמט ידידותי למשתמש. המגבלה העיקרית של ה-View היא שהוא לא אמור לשנות את המודל בשום צורה. המטרה העיקרית של הבקר היא לעבד פעולות משתמש. באמצעות הבקר המשתמש מבצע שינויים במודל. ליתר דיוק, לתוך הנתונים המאוחסנים במודל. תנו לנו לתת שוב את התרשים שכבר הוצג לכם בהרצאה: מכל זה נוכל להסיק מסקנה הגיונית לחלוטין. יש לחלק מערכת מורכבת למודולים. הבה נתאר בקצרה את השלבים כיצד להשיג הפרדה כזו.

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

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

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

כאן אנו שואפים ל-2 מטרות:

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

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

שלב 3. חלוקת הממשק ל-View ו-Controller

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

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

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

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

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

קצת על היחס בין התצוגה והבקר והדגם

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

MVC: מה היתרון?

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