locked
חו"ד על מימוש מסויים של - PRISM RRS feed

  • שאלה

  • אני מתחיל ללמוד עכשיו PRISM ומנסה להבין את הארכיטקטורה.

    המדריך של מיקרוסופט לא תמיד ברור (ומאוד ארוך) ונתקלתי במדריך המקוצר הבא:

    Link

    ניסיתי להסתכל בכמה דוגמאות של אפליקציות PRISM כמו STOCKTRADER של MICROSOFT

    וכל האופן בין החיבור של ה-View ל-ViewModel נראה קצת שונה בין המימושים.

    בפתרון של CODEPROJECT ממליצים ליצור 2 ממשקים:

    public interface IView
    {
      IViewModel ViewModel {get; set;}
    }
    
    public interface IViewModel
    {
      IView View {get; set;}
    }


    לאחר מכן לקחת את אחד המסכים שלנו וליצור עבורו גם ממשק שיירש מ-View


    public interface IMenuBarView: IView { }


    ב-CodeBehind של ה-View שלנו לממש את הממשק מעלה:

    public partial class MenuBarView: UserControl, IMenuBarView
    { 
      public MenuBarView()
      { 
       InitializeComponent();
      }
      public IViewModel ViewModel
      {
       get{ return (IMenuBarViewModel)DataContext;}
       set{ DataContext = value; }
      }
    }


    בלממש את IViewModel בתוך IMenuBarViewModel

    public interface IMenuBarViewModel: IViewModel
    {
      public MenuBarView()
      { 
       InitializeComponent();
      }
    
    }


    ואז ב-ViewModel לבצע את ההשמה הבאה:

    public class MenuBarViewModel: IMenuBarViewModel
    {
     public MenuBarViewModel( IMenuBarView view)
     {
      View = view; 
      View.ViewModel = this;
     }
     public IView View 
     {get; set;}
    }

    הפתרון הזה נראה לי קצת כמו "ספגטי". האם זו עבודה תקנית ב-PRISM?

    אני מתחיל פרויקט גדול ורוצה להתחיל בצורה טובה. מה אתם חושבים על המימוש?


    • נערך על-ידי ofir_bl יום רביעי 05 דצמבר 2012 20:29 Mistakes
    יום רביעי 05 דצמבר 2012 20:24

תשובות

  • הי אופיר,

    אשתדל לענות בקצרה, שכן הנושא אינו פשוט ורק הניסיון מלמד שיש יותר מדרך אחת נכונה לארכיטקטורה בעזרת Prism, וזה מאוד תלוי באופי הפרויקט.

    בגדול, Prism בא לתת פתרון לבניית אפליקציה מרוכבת (Composite Application), אפליקציה שמורכבת ממספר מודולים, כאשר כל מודול הינה יחידה עצמאית, בלתי תלויה במודולים אחרים. הדרך להעביר מידע בין מודולים היא בעזרת Services ו/או Loosely Coupled Events.

    עם הזמן, הוסיפו ל- Prism יכולות כמו טיפול ב-Navigation, MVVM וכו'.

    ניתן גם להשתמש ב- Prism כתשתית לבניית UI שהוא לא בהכרח מרוכב.

    מה שאתה מתאר זה רק צד אחד של הבעיה ש- Prism בא לתת מענה, וזה נפתר בעזרת pattern שנקרא: MVVM.

    הרעיון המרכזי זה לבצע הפרדה בין ה- View לבין הלוגיקה העסקית שמחברת את ה- View הזה למערכת, וזה בשל: Testing, UI Design, קריאות, חלוקה נכונה של קוד, וכו'.

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

    כשכותבים UI ב- WPF או SL, ניתן לנצל את מנגנון ה- Binding. בעזרתו ניתן לבצע את ההפרדה, כך שהממשק בין ה- View לבין ה- ViewModel מתבצע בעזרת Properties, אותם מכירים מתוך ה- XAML ועליהם עושים Binding.

    כמובן שיש חסרון למנגנון זה כי הממשק לכאורה לא Typed ואפשר לעשות טעויות, אבל זה מנגנון שהוכיח, ומוכיח את עצמו כמנגנון מאוד גמיש ונוח, שמקצר מהותית את זמני הפיתוח.

    אז אם אסכם, מה שצריך זה ViewModel עם Properties, ו-View שבגדול לא אמור להיות לו Code Behind. ב-XAML עושים Binding ל-Properties של ה- ViewModel. לכל View יש ViewModel אחד בלבד, וההיפך. כמובן של-View יכולים להיות מצבים שונים של תצוגה, אבל זה לא בהכרח עוד View.

    כמובן שבמציאות יש דברים מורכבים יותר, ופה יש מקום ל- Commands ו- Attached Behaviors.

    http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

    לגבי שאלתך השנייה, בגדול כמט כל מה שנכתב בעזרת Attribute ניתן לכתוב ללא, הרעיון זה אלגנטיות, פשטות בכתיבת ובמקרים מסויימים AOP.

    אם אתה מתחיל פרוייקט גדול, הייתי ממליץ לך לקחת ייעוץ, זה יחסוך לך המון זמן וכסף בעתיד.

    בהצלחה!

    תומר שמם,

    CodeValue

    http://blogs.microsoft.co.il/blogs/tomershamam


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • הוצע כתשובה על-ידי תומר שמםModerator שבת 08 דצמבר 2012 19:01
    • סומן כתשובה על-ידי Eran Sharvit יום שלישי 11 דצמבר 2012 08:14
    שבת 08 דצמבר 2012 19:01
    מנחה דיון
  • הי,

    בגדול תשתמש ב- View Model Locator.

    זה יאפשר להחליף את ה- VM לצרכי Design Time ו- UT.

    זה לא משנה מאיפה מבצעים את החיבור (קוד או XAML), העיקר ש:

    1. תהיה הפרדה נכונה
    2. תהיה תמיכה ב- Design Time
    3. תהיה אפשרות לעשות UT


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • סומן כתשובה על-ידי ofir_bl יום שלישי 11 דצמבר 2012 09:02
    יום שלישי 11 דצמבר 2012 08:21
    מנחה דיון

כל התגובות

  • אני אנצל את השרשור לשאלה נוספת, 

    ראיתי שיש 2 אפשרויות שונות לאתחל מודולים ב PRISM,

    1. ע"י מנגנון ה-Initializing

    2. ע"י הגדרת Attributes.

    מלבד ההבדל ב-Syntax, האם יש הבדלים נוספים בין השיטות?

    יום חמישי 06 דצמבר 2012 12:02
  • הי אופיר,

    אשתדל לענות בקצרה, שכן הנושא אינו פשוט ורק הניסיון מלמד שיש יותר מדרך אחת נכונה לארכיטקטורה בעזרת Prism, וזה מאוד תלוי באופי הפרויקט.

    בגדול, Prism בא לתת פתרון לבניית אפליקציה מרוכבת (Composite Application), אפליקציה שמורכבת ממספר מודולים, כאשר כל מודול הינה יחידה עצמאית, בלתי תלויה במודולים אחרים. הדרך להעביר מידע בין מודולים היא בעזרת Services ו/או Loosely Coupled Events.

    עם הזמן, הוסיפו ל- Prism יכולות כמו טיפול ב-Navigation, MVVM וכו'.

    ניתן גם להשתמש ב- Prism כתשתית לבניית UI שהוא לא בהכרח מרוכב.

    מה שאתה מתאר זה רק צד אחד של הבעיה ש- Prism בא לתת מענה, וזה נפתר בעזרת pattern שנקרא: MVVM.

    הרעיון המרכזי זה לבצע הפרדה בין ה- View לבין הלוגיקה העסקית שמחברת את ה- View הזה למערכת, וזה בשל: Testing, UI Design, קריאות, חלוקה נכונה של קוד, וכו'.

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

    כשכותבים UI ב- WPF או SL, ניתן לנצל את מנגנון ה- Binding. בעזרתו ניתן לבצע את ההפרדה, כך שהממשק בין ה- View לבין ה- ViewModel מתבצע בעזרת Properties, אותם מכירים מתוך ה- XAML ועליהם עושים Binding.

    כמובן שיש חסרון למנגנון זה כי הממשק לכאורה לא Typed ואפשר לעשות טעויות, אבל זה מנגנון שהוכיח, ומוכיח את עצמו כמנגנון מאוד גמיש ונוח, שמקצר מהותית את זמני הפיתוח.

    אז אם אסכם, מה שצריך זה ViewModel עם Properties, ו-View שבגדול לא אמור להיות לו Code Behind. ב-XAML עושים Binding ל-Properties של ה- ViewModel. לכל View יש ViewModel אחד בלבד, וההיפך. כמובן של-View יכולים להיות מצבים שונים של תצוגה, אבל זה לא בהכרח עוד View.

    כמובן שבמציאות יש דברים מורכבים יותר, ופה יש מקום ל- Commands ו- Attached Behaviors.

    http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

    לגבי שאלתך השנייה, בגדול כמט כל מה שנכתב בעזרת Attribute ניתן לכתוב ללא, הרעיון זה אלגנטיות, פשטות בכתיבת ובמקרים מסויימים AOP.

    אם אתה מתחיל פרוייקט גדול, הייתי ממליץ לך לקחת ייעוץ, זה יחסוך לך המון זמן וכסף בעתיד.

    בהצלחה!

    תומר שמם,

    CodeValue

    http://blogs.microsoft.co.il/blogs/tomershamam


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • הוצע כתשובה על-ידי תומר שמםModerator שבת 08 דצמבר 2012 19:01
    • סומן כתשובה על-ידי Eran Sharvit יום שלישי 11 דצמבר 2012 08:14
    שבת 08 דצמבר 2012 19:01
    מנחה דיון
  • שלום תומר,

    ראשית תודה רבה על תשובתך.

    אני מכיר MVVM, עד כה יצא לי לעבוד די עצמאית עם MVVM והקוד המוכן שלקחתי היה מזה של MVVM LIGHT.

    כעת אני מעוניין ללמוד איך זה עובד עם PRISM (די התקדמתי עם זה). על מנת ליצור קישור בין ה VIEWS שלי ל VIEW MODELS יש את הדרך שהצגתי מעלה ויש אפשרות לבצע זאת דרך ה XAML (אני מניח שיש אפשרויות נוספות).

    השאלה שלי הייתה ספציפית לנושא הזה, האם אתם ממליצים לבצע את החיבור דרך ה XAML? אינטואיטיבית זה נראה לי פחות גמיש אם ארצה להחליף DATACONTEX ב-RUNTIME ל-VIEW מסוים, האין זה כך?

    כמוכן במידה ומומלץ לבצע זאת דרך הקוד, כיצד הייתם ממליצים לעשות זאת?

    תודה מראש על עזרה,

    אופיר

    שבת 08 דצמבר 2012 21:52
  • הי,

    בגדול תשתמש ב- View Model Locator.

    זה יאפשר להחליף את ה- VM לצרכי Design Time ו- UT.

    זה לא משנה מאיפה מבצעים את החיבור (קוד או XAML), העיקר ש:

    1. תהיה הפרדה נכונה
    2. תהיה תמיכה ב- Design Time
    3. תהיה אפשרות לעשות UT


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • סומן כתשובה על-ידי ofir_bl יום שלישי 11 דצמבר 2012 09:02
    יום שלישי 11 דצמבר 2012 08:21
    מנחה דיון