שנת 2010 בתחום ה-UI היתה שנת ה-MVVM . בהרבה חברות שעבדתי בשנת 2010 בחרו בפה אחד לעבוד ע"פ ה-Pattern של M-V-VM. למה? אמרו לי שיותר קל לכתוב בדיקות, במה זה מתבטא? ומה קרה שנטשנו את ה- MVC או את ה-MVP ? בפוסט זה אני אנסה להסביר את הסיבות למה אני בחרתי ב-MVVM ומה חסר.
טענה: ה-MVVM עוזר לנו לכתוב קוד שעושה הפרדה בין חלקי ה-UI ללוגיקה של המסך.
כאשר מסתכלים על המסך הפשוט הזה מגלים שיש המון צורות לכתוב אותו.
גירסת ה-"VB" ( לחיצה כפולה על פקד ה-Send )
public partial class MainWindow : Window{
...
private void btnSendMail_Click(object sender, RoutedEventArgs e)
{
string to = tbTo.Text;
string subject = tbSubject.Text;
string msg = tbMsg.Text;
proxy.SendMail(to, subject, msg);
}
}
הקוד הזה מאוד אינטואינטיבי, מאוד פשוט, אך מאוד בעייתי. יש פה קשר בין הפקד ה-UI לבין הלוגיקה.
אם מחר אני ארצה לעבור מפקד TextBox אחד לפקד TextBox גירסה 2, או פקד אחר שאין לו את ה-Property של ה-Text. אני יכול לקבל התנהגות שונה לגמרי.
איך אפשר לשפר את זה?
public partial class MainWindow : Window{
public string To { get; set; }
public string Subject { get; set; }
public string Message { get; set; }
private void btnSendMail_Click(object sender, RoutedEventArgs e)
{
proxy.SendMail(To, Subject, Message);
}
}
בשינוי הקטן שבו כל הקוד עובד מול ה- Properties ולא מול הפקדים אני מנתק את התלות שלי ב-UI. נשמע כל כך פשוט, אפילו טריוויאלי... אז למה כל פעם שאני מגיע לפרויקט גדול אני רואה בקוד, בעיקר בקוד של החלונות וה-UserControls נגיעה בפקדים במספר מקומות ולא עבודה רק מול ה- Properties? למשל פניה ל- ListBox.SelectedItem. לפי דעתי ,הסיבה לכך היא, שאנחנו כותבים קוד בחלון וכל ה- Properties של הפקדים נגישים לנו, אז אנחנו מתעצלים לכתוב שוב את ה- Properties בחלון ולעבוד מולם. בנוסף, צריך לעשות הפרדה בין מידע לוגי שקיים בפקד למידע ויזואלי. רק למידע הלוגי צריך לכתוב Property ולא למידע ויזואלי.
Read more: I Love C#