מה הסוד של M-V-VM

שנת 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#

Posted via email from .NET Info