Question from .Net Forum: What's the difference between MVC and 3Tier Architecture
שאלה: מה ההבדל בין ארכיטקטורת MVC לבין ארכיטקטורת 3Tier?
תשובה:
3Tier או כל ארכיטקטורת שכבות אחרת מדברת על "יש לי פרוייקט א' שתלוי בפרוייקט ב' שתלוי בפרוייקט ג'" וממשיך עד תלוי בפרוייקט X. ארכיטקטורת 3Tier אומרת שיש תלות של ה-GUI על ה-DAL שלו בתורו יש תלות על ה-BL או שיש ל-GUI תלות על ה-BL שיש לו תלות על ה-DAL. הקונספט הוא הרבה פחות קונספט לוגי של אחריות והפרדה, אלא הרבה יותר קונספט של לארגן את המחלקות עצמן בקבוצות אחריות מוכרות וידועות. למשל, ב-GUI יהיה לי רק טפסים שפונים לישויות ב-BL שבתורן כותבות את עצמן באמצעות מתודות מה-DAL.
MVC (או MVC משופר שכתב לאחרונה פאולר או MVP שהוא שכלול של MVC) מסתמכים הרבה יותר על חלוקה לוגית של אחריות ושל הפרדת "מי מדבר עם מי". ב-MVC יש שלושה גם שלושה שחקנים עיקריים: Model שמכיל בתוכו את המידע עצמו בצורה של ישות מידע, View שהוא ה-GUI שנחשף למשתמש וה-Controller. עכשיו ה-Controller הוא המקום שההבדל באמת מגיע. במודלי שכבות אין מניעה שבו למשל ה-GUI יהיה זה שיוצר טיפוס BL חדש (למשל "פרה" חדשה בשם עדנה באחו מספר 3) ואז יגיד ל-DAL "אתה תשתמור את עדנה במסד נתונים". ב-MVC אסור ל-View לנשום אפילו באזור של המסד נתונים. ה-Controller נרשם לאירועים ב-View (כגון לחיצת כפתור, סגירת טופס ושינוי טקסט) והוא בתורו היחידי שבאמת יודע מה הקשר בין ה-TextBox לשם של הפרה ובין ה-DropDownList לאחו בו רועה הפרה. ככה שיוצא שה-View רק באמת מטפל בסוגיות של תצוגה וה-Controller רק באמת מטפל בסוגיות של שינוי מידע.
ההגבלה של MVCים למיניהם הרבה יותר חזקה מההגבלה של מודלי שכבות למיניהם. זה בגלל שבנוסף להפרדת השכבות שמשתמעת ב-MVCים (למרות שלמשל את עצם קיומו של DAL לא מניחים במפורש ב-MVC אלא אומרים "אלו יהיו Helper Methods") יש גם את הכלל שבו ה-GUI עצמו בכלל לא יודע את התוצאות של מה שקורה בו. מה שלא נכון ב-3Tier כי אני באותה מידה יכול ליצור מתודה של כפתור שדואגת לשמירה ועדכון במסד הנתונים גם אם הוא לא מדבר איתו בשום שלב ישירות אלא רק דרך מתודות של ה-DAL או ה-BL.
שאלת המשך: אצלי הGUI אף פעם לא ניגש ישירות לDAL, חשבתי שזו הדרך הכי הגיונית... למה לאפשר כזו גישה ישירה?
תשובת המשך:
מה שאתה אומר לא מדוייק, ה-GUI שלך כנראה מאוד לא ניגש ישירות ל-DAL אבל יוזם במודע ובאופן ישיר מצב שבו ה-DAL יהיה חייב להיכנס לפעולה. למשל אם יש לנו טופס "יצירת פרה" וכפתור Submit בארכיטקטורת 3Tier ככה יראה הקוד שלך:
protected void btnCreateCow_Click(object sender, EventArgs e) {
Cow myNewCow = new Cow();
myNewCow.Name = tbxCowName.Text;
myNewCow.Create();
}
זה היה במקרה שה-BL שלך מכיל את ה-DAL בתוכו או במקרה שה-DAL מכיל בתוכו את ה-BL זה יראה כך:
protected void btnCreateCow_Click(object sender, EventArgs e) {
Cow myNewCow = new Cow();
myNewCow.Name = tbxCowName.Text;
CowDAL.Create(myNewCow);
}
עכשיו ככה הקוד היה נראה ב-3Tier אבל טוען פאולר ובצדק שהקוד הזה בעייתי. הבעיה היא שה-GUI שלנו יודע במפורש שלחיצה על כפתור מובילה ליצירת פרה חדשה, עוד יותר גרוע הוא גם יודע ש-tbxCowName הוא השם של הפרה החדשה ואפילו עוד יותר גרוע יוצר במפורש או במשתמע פנייה ל-DAL. זה המון התנהגות להכניס ל-GUI. המון.
הקוד הזה גם יכול להיות עוד יותר נורא בזה שנגיד שקיים DropDownList ב-GUI של "אחו" לפרה ואז לפי ה-ID הנבחר ב-DropDownList נצטרך לקבוע את האחו של הפרה:
protected void btnCreateCow_Click(object sender, EventArgs e)
{
Cow myNewCow = new Cow();
myNewCow.Name = tbxCowName.Text;
myNewCow.Meadow = Meadow.Find(BLHelper.SelectIndexToId(ddlMedows.SelectedIndex));
myNewCow.Create();
}
עכשיו נתנו ל-GUI שלנו לא רק אחריות על יצירת פרה חדשה אלא היא גם יוצרת את הקשרים בין הישויות ועוד יותר גרוע מתרגמת את המשמעות של המידע ב-GUI למידע עסקי.
ב-MVC היינו יוצרים View בצורה של טופס חדש עם למשל TextBoxים, DropDownListים וכפתור שיחשוף את האירועים של שינוי פקדים ולחיצה על פקדים ובנוסף את המאפיינים (באנגלית: Properties). ה-Controller שלנו ירשם לאירועים וספציפית ירשם לאירוע לחיצה על כפתור, הוא יצור Modal חדש (במקרה שלנו, פרה) והוא זה שיהיה אחראי לתרגם מ-myCowNameText (שזה מאפיין שיחשוף ה-View) את הערך לתוך השם של הפרה. כלומר, ה-Controller הוא זה שמגשר בפועל בין View לבין Modal. ל-View שהוא GUI אסור בשום שלב ליצור אובייקטים עסקיים חדשים ובטח שלא ליזום ישירות פעולות שנוגעות לעבודה עם מידע. ה-View הוא באמת רק זה.
קישור: http://www.tapuz.co.il/tapuzforum/main/Viewmsg.asp...