MVVM Light
- פותח הנושא yoave23
- פורסם בתאריך
תשובה
ראשית, אני ממליץ על פריזם. זו חבילה מקיפה ומודולרית, עם פתרונות להרבה אתגרים.
כאמור, זו חבילה מודולרית שבנויה מכמה חבילות. הבסיסית, שמקבילה לMvvmLight, נקראת Prism.Mvvm.
וכעת, תשובה לשאלתך. כדי לתכנת בשיטת MVVM, צריך בעיקר שלשה דברים:
1. ViewModelBase. כדי שלא תצטרך לממש בכל פעם את INotifyPropertyChanged.
המקביל לזה בפריזם: BindableBase.
2. RelayCommand, זה לוקח מתודות, ועוטף אותן בצורה שהView יכול להפעיל אותן.
המקביל לזה בפריזם: DelegateCommand. [המקביל הפריזמאי תומך גם בפקודות אסינכרוניות]
3. Messanger, כדי להעביר מידע בין חלקי האפליקציה, בלי שהם יידעו אחד מהשני.
המקביל לזה בפריזם: PubSubEvent. [לדעתי, פריזם מממשים את הרעיון בצורה הרבה יותר מובנת וטובה]
ובנוסף, DI.
4. כל תכנות מודרני נעשה בשיטת הזרקת תלויות [DI].
MvvmLight מספק קונטיינר שמזריק תלויות.
ראשית, אני ממליץ על פריזם. זו חבילה מקיפה ומודולרית, עם פתרונות להרבה אתגרים.
כאמור, זו חבילה מודולרית שבנויה מכמה חבילות. הבסיסית, שמקבילה לMvvmLight, נקראת Prism.Mvvm.
וכעת, תשובה לשאלתך. כדי לתכנת בשיטת MVVM, צריך בעיקר שלשה דברים:
1. ViewModelBase. כדי שלא תצטרך לממש בכל פעם את INotifyPropertyChanged.
המקביל לזה בפריזם: BindableBase.
2. RelayCommand, זה לוקח מתודות, ועוטף אותן בצורה שהView יכול להפעיל אותן.
המקביל לזה בפריזם: DelegateCommand. [המקביל הפריזמאי תומך גם בפקודות אסינכרוניות]
3. Messanger, כדי להעביר מידע בין חלקי האפליקציה, בלי שהם יידעו אחד מהשני.
המקביל לזה בפריזם: PubSubEvent. [לדעתי, פריזם מממשים את הרעיון בצורה הרבה יותר מובנת וטובה]
ובנוסף, DI.
4. כל תכנות מודרני נעשה בשיטת הזרקת תלויות [DI].
MvvmLight מספק קונטיינר שמזריק תלויות.
כן, אני, ואל תיגע בפריזם אם שפיותך יקרה לך
עבדתי עם MVVMLight הרבה, זו חבילה קטנטונת ונהדרת, עכשיו אני כבר איזה חצי שנה עובד עם קאליברן, ואיך לומר, מסתדר איתו אבל אנחנו לא חברים
עכשיו תשאל מה שבא לך על WPF ואני אענה לך כמיטב יכולתי, יש לי בסביבה הזו לא רק הרבה ניסיון, אלא גם הרבה אהבה לשיטת העבודה הזו ולדרך המאד מוצלחת שמיקרוסופט מימשו את זה. גם WPF גם סילברלייט וגם Windows8/Phone
בהצלחה,
זיו
עבדתי עם MVVMLight הרבה, זו חבילה קטנטונת ונהדרת, עכשיו אני כבר איזה חצי שנה עובד עם קאליברן, ואיך לומר, מסתדר איתו אבל אנחנו לא חברים
עכשיו תשאל מה שבא לך על WPF ואני אענה לך כמיטב יכולתי, יש לי בסביבה הזו לא רק הרבה ניסיון, אלא גם הרבה אהבה לשיטת העבודה הזו ולדרך המאד מוצלחת שמיקרוסופט מימשו את זה. גם WPF גם סילברלייט וגם Windows8/Phone
בהצלחה,
זיו
עם כל הכבוד
יש לי הרבה כבוד ותודה לזיו. הוא האדם שהדריך אותי בצעדיי הראשונים בWPF, הוא סיפר לי על MVVM, עזר לי הרבה, והוציא אותי ממבוכות ותעיות-טעויות-תהיות.
אבל "אהוב סוקרטס, אהוב אפלטון, והאמת אהובה משניהם". ולכן, אינני מהסס לגלות דעתי, שזיו תקוע בשיטות עבודה מיושנות, ולכן הוא מאשים את פריזם.
מה אנחנו יודעים על שיטות העבודה של זיו:
1. איננו אוהב יוניט-טסטים, ואיננו משתמש בהם כלל, אלא מריץ את האפליקציה ובודק ידנית.
2. איננו משתמש בIoc ואפילו לא בDependencyInjection. [באמת מי שלא משתמש ביוניטטסטים, אין לו צורך בDI]
3. איננו רואה צורך להפריד בין שכבת הView לשכבת הViewModel. כל הדיבורים על "ViewModel לא מכיר את הView" הם בעיניו פילוסופיות מיותרות וריקות מתוכן.
למותר לציין, שאינני נביא ולא בן נביא, אלא מצטט דברים שזיו כתב.
שיטת העבודה של זיו איננה MVVM, כי הדבר היחיד שהוא לוקח מMVVM, זה מנגנון הבינדינג והקוממנדס. אמנם אלו דברים חשובים וטובים, אבל אין בכך כדי להקרא MVVM. כי MVVM נוצר בשביל יוניטטסטים. MVVM נוצר בשביל DI. ואסור בתכלית האיסור שהViewModel יכיר את הView.
אבל זיו, שלא הסכין לכל אלו, ניסה את פריזם, ונתקל בחבלי הילדות של שימוש בDI. במקום לצלוח את המשוכה ולרוץ קדימה, הוא נמלט אל האחות הקטנה MVVMLight.
אבל גם את MVVMLight הוא איננו ממצה, כי כנראה הוא איננו משתמש בServiceLocator שהוא מרכיב בסיסי של MVVMLight.
ועכשיו כמה מילים על פריזם:
פריזם איננו דבר אחד, אלא אוסף שיטות ופתרונות, חלקם הכרחיים לכל מתכנת WPF, וחלקם מתאים במיוחד לפרוייקטים גדולים.
MVVMLight, מספק חלק מאוסף השיטות השלם שנקרא "פריזם".
גם פריזם עצמה היא מודולרית ומאפשרת להשתמש רק בחלקים מהאוסף. דוגמאות:
Prism.Mvvm מספקת פתרון פתרון פשוט לבינדינג.
Prism.Interactivity מספק פתרון לאינטרקציות [דיאלוגים והודעות למשתמש].
וכן Prism.Modularity, Prism.PubsubEvents וכו' וכו', כל אחד נותן פתרון ממוקד לאתגר ספציפי.
אין לי דבר נגד MvvmLight, זה אכן מתאים מאד לפרוייקטים קטנים ופשוטים, אבל לא לפרויקטים מורכבים ומודולריים עם UI גמיש.
קחו דוגמא: בטח שמעתם על תוכנה בשם VisualStudio ועל Blend. אלו שתי תוכנות מורכבות וידועות, שנכתבו ב...WPF. התוכנות האלו, נכתבות על ידי הרבה צוותים באופן מודולרי. צוות אחד עובד על LocalsWindow, וצוות אחר על SolutionExplorer, ובמקום אחר עובד צוות על CodeLens. אחרי שהתוכנה יצאה לשוק, פתאום החליטו להוסיף לה עוד מודול: Performance Profiler.
איך עשו את זה? אינני יודע האם עשו זאת עם פריזם או עם דבר אחר באותה רמה, אבל ברור שלא עם MVVMLight.
יש לי הרבה כבוד ותודה לזיו. הוא האדם שהדריך אותי בצעדיי הראשונים בWPF, הוא סיפר לי על MVVM, עזר לי הרבה, והוציא אותי ממבוכות ותעיות-טעויות-תהיות.
אבל "אהוב סוקרטס, אהוב אפלטון, והאמת אהובה משניהם". ולכן, אינני מהסס לגלות דעתי, שזיו תקוע בשיטות עבודה מיושנות, ולכן הוא מאשים את פריזם.
מה אנחנו יודעים על שיטות העבודה של זיו:
1. איננו אוהב יוניט-טסטים, ואיננו משתמש בהם כלל, אלא מריץ את האפליקציה ובודק ידנית.
2. איננו משתמש בIoc ואפילו לא בDependencyInjection. [באמת מי שלא משתמש ביוניטטסטים, אין לו צורך בDI]
3. איננו רואה צורך להפריד בין שכבת הView לשכבת הViewModel. כל הדיבורים על "ViewModel לא מכיר את הView" הם בעיניו פילוסופיות מיותרות וריקות מתוכן.
למותר לציין, שאינני נביא ולא בן נביא, אלא מצטט דברים שזיו כתב.
שיטת העבודה של זיו איננה MVVM, כי הדבר היחיד שהוא לוקח מMVVM, זה מנגנון הבינדינג והקוממנדס. אמנם אלו דברים חשובים וטובים, אבל אין בכך כדי להקרא MVVM. כי MVVM נוצר בשביל יוניטטסטים. MVVM נוצר בשביל DI. ואסור בתכלית האיסור שהViewModel יכיר את הView.
אבל זיו, שלא הסכין לכל אלו, ניסה את פריזם, ונתקל בחבלי הילדות של שימוש בDI. במקום לצלוח את המשוכה ולרוץ קדימה, הוא נמלט אל האחות הקטנה MVVMLight.
אבל גם את MVVMLight הוא איננו ממצה, כי כנראה הוא איננו משתמש בServiceLocator שהוא מרכיב בסיסי של MVVMLight.
ועכשיו כמה מילים על פריזם:
פריזם איננו דבר אחד, אלא אוסף שיטות ופתרונות, חלקם הכרחיים לכל מתכנת WPF, וחלקם מתאים במיוחד לפרוייקטים גדולים.
MVVMLight, מספק חלק מאוסף השיטות השלם שנקרא "פריזם".
גם פריזם עצמה היא מודולרית ומאפשרת להשתמש רק בחלקים מהאוסף. דוגמאות:
Prism.Mvvm מספקת פתרון פתרון פשוט לבינדינג.
Prism.Interactivity מספק פתרון לאינטרקציות [דיאלוגים והודעות למשתמש].
וכן Prism.Modularity, Prism.PubsubEvents וכו' וכו', כל אחד נותן פתרון ממוקד לאתגר ספציפי.
אין לי דבר נגד MvvmLight, זה אכן מתאים מאד לפרוייקטים קטנים ופשוטים, אבל לא לפרויקטים מורכבים ומודולריים עם UI גמיש.
קחו דוגמא: בטח שמעתם על תוכנה בשם VisualStudio ועל Blend. אלו שתי תוכנות מורכבות וידועות, שנכתבו ב...WPF. התוכנות האלו, נכתבות על ידי הרבה צוותים באופן מודולרי. צוות אחד עובד על LocalsWindow, וצוות אחר על SolutionExplorer, ובמקום אחר עובד צוות על CodeLens. אחרי שהתוכנה יצאה לשוק, פתאום החליטו להוסיף לה עוד מודול: Performance Profiler.
איך עשו את זה? אינני יודע האם עשו זאת עם פריזם או עם דבר אחר באותה רמה, אבל ברור שלא עם MVVMLight.
Royi Namir
New member
יונה , הגישה היא לא לעניין
יש הבדל בין לחלוק על דעותיו/פעולותיו של אדם X לבין לרשום:
אדם X לא משתמש , "נמלט אל" , במקום להתמודד - וויתר
זה לא מחזק שום צד ובטח שלא תורם לדיון
כקורא מהצד , אני חייב לרשום.
אין ספק שוויתור על הלוואים היה יותר ענייני.
 
יש הבדל בין לחלוק על דעותיו/פעולותיו של אדם X לבין לרשום:
אדם X לא משתמש , "נמלט אל" , במקום להתמודד - וויתר
זה לא מחזק שום צד ובטח שלא תורם לדיון
כקורא מהצד , אני חייב לרשום.
אין ספק שוויתור על הלוואים היה יותר ענייני.
 
מסכים עם דבריך באופן חלקי
וכמובן שדבריך אינם מדוייקים בעליל, במיוחד לגבי הדברים שבהם אתה מתיימר להבין את דעותיי וגישתי לדברים
MVVM הוא תבנית עיצוב, ולכן אינו כולל בתוכו את השימוש ב-IOC או DI שהן תבניות עיצוב נוספות, ובלתי קשורות לחלוטין. גם בנוגע לתבניות עיצוב אלה, ישנן שיטות שונות לממש אותן וגישות שונות וחלקיות או מלאות לממש אותן, וישנן הרבה דעות לגבי נחיצותן של אלה ושל אלה. אתה מביא את הדברים (לפחות להבנתי הצולעת) כאילו או שאדם משתמש ב-MVVM מתחילתו ועד סופו, או שאינו נקרא מיישם MVVM כלל, כנל לגבי השימוש ב-IOC או DI. זו גישה שלטעמי היא שגויה ומובילה בראש ובראשונה להרבה מאד עבודה ובהמשך מגלים שריבוי העבודה לא הביא תועלת מרובה כפי שניתן היה לחשוב בתחילת העבודה.
אין לי גישה של "אוהב" או "לא אוהב" יוניט-טסטים, אני עושה את זה אם צריך, והתייחסתי רבות לצורך בבדיקות-יחידה בהתאם לגודל הפרוייקט והשלב בו הוא נמצא, ומספר האנשים שמעורבים בו. כרגע למשל אני חלק מפרוייקט שבו משתמשים בהן, ולכן אני מממש בדיקות שכאלה, ולפני שבוע העברתי קומיט של קוד לאחר שהעברתי אותו דרך משהו כמו 100 בדיקות שונות, ולאחר שעבר את כולן בהצלחה, רק ששכחתי להריץ את הפרוייקט, ורגע אחרי שעשיתי PUSH גיליתי שהפרוייקט לא עולה בכלל (מסתבר שזה בגלל attribute שהיה חסר - DataContract). אני לא בא לומר שאלה או אלה לבדם הם חיוניים, אלא שיש להשתמש גם באלה וגם באלה בצורה מדודה.
אני *כן* משתמש (לפחות בפרוייקט הנוכחי) ב-IoC - וגם פה יש הרבה מאד יתרונות והרבה מאד בעיות. לדוגמה קטנה מהקטנות, אם דברים לא עובדים כמצופה, יש הרבה יותר קושי למצוא למה, מאשר בדרך שבה אני הוא היוצר את האובייקטים. עבדתי במספר פרוייקטים שבהם עשו שימוש ב-DI/IoC שבעצם לא הביא הרבה תועלת, אבל מצד שני יצר המון קשיים, ולכן הגישה שלי היא פרקטית, כלומר מה שעובר ומה שעוזר זה מה שצריך לעשות. באחד המקומות שבהם עבדתי והיה שם את השימוש המאסיבי ביותר גם בבדיקות וגם ב-DI הקצב של התקדמות הפיתוח היה איטי עד אפסי, ובדיעבד חלק גדול מזה נגרם מהשימוש (חלקו לקוי) בשיטות אלה. אלה שיטות שקל מאד לעשות להן abuse וקשה מאד להבין איך בדיוק צריך לעבוד איתן והיכן כן והיכן לא, ובמקום שבנאדם ישב וילמד אלף דברים בשביל אפליקציה של ספר טלפונים, ההמלצה שלי היא פשוט לכתוב את התוכנה כך שתציג ספר טלפונים. אם בשלב מאוחר יותר ספר-הטלפונים הופך למערכת CRM רב-שכבתית, יהיה בכל מקרה צורך לשנות את הארכיטקטורה מתחילתה ועד סופה, ובין השאר כנראה יהיה צורך להכניס IOC או DI ובדיקות-יחידה.
מעולם לא טענתי שאין צורך להפריד את שכבת ה-VIEW משכבת VM, טענתי (אם זכרונני איננו מטעני) שלגבי MODEL ו-VM, לרוב המימוש של שכבת המודל הוא בעזרת ORM כלשהו, וזה ממומש ע"י EF ודומיו, שגם דואג לממש נוטיפיקציות על שינוי, ולכן אין באמת שכבת מודל שצריך לטרוח עליה כמו על שכבת ה-VM. בנוסף אמרתי שלפעמים הדרך הכי מוצלחת היא להשתמש ב-VIEW ובקוד שלו ע"מ לבצע משימה, אני לא חושב שזו הדרך המיטבית אבל כמו תמיד אם בהמשך מתגלה בעיה, עושים refactoring ומשנים את מבנה הקוד.
הטענה העיקרית שלי היא שצריך להיות כל הזמן הם העיניים על המטרה, ולא עם העיניים תקועות בספר של איך נכון לעבוד, כי יש המון שיטות נכונות לעבוד, ולא תמיד כולן מסייעות למוצר או למתכנת או ללקוח, אלא בעיקר למי שכתב את הספר. מה שעובד, ברוך הבא, מה שלא עובד, הראו לו את הדלת.
הדעה שלי לגבי פריזם לא נסמכת אך ורק על ניסיוני עם סביבה זו, אלא בעיקר על פרויקטים שראיתי שמומשו בפרוייקטים שהגעתי אליהם לאחר שכבר היו בנויים זמן רב, ובעיקר משיחות שהיו לי עם אנשים נוספים שאני מעריך את דעתם בנוגע לסביבה הזו, וגם דעתם לא הייתה נוחה מהשימוש המורכב מאד באופן יחסי בסביבה זו.
בברכה,
זיו
וכמובן שדבריך אינם מדוייקים בעליל, במיוחד לגבי הדברים שבהם אתה מתיימר להבין את דעותיי וגישתי לדברים
MVVM הוא תבנית עיצוב, ולכן אינו כולל בתוכו את השימוש ב-IOC או DI שהן תבניות עיצוב נוספות, ובלתי קשורות לחלוטין. גם בנוגע לתבניות עיצוב אלה, ישנן שיטות שונות לממש אותן וגישות שונות וחלקיות או מלאות לממש אותן, וישנן הרבה דעות לגבי נחיצותן של אלה ושל אלה. אתה מביא את הדברים (לפחות להבנתי הצולעת) כאילו או שאדם משתמש ב-MVVM מתחילתו ועד סופו, או שאינו נקרא מיישם MVVM כלל, כנל לגבי השימוש ב-IOC או DI. זו גישה שלטעמי היא שגויה ומובילה בראש ובראשונה להרבה מאד עבודה ובהמשך מגלים שריבוי העבודה לא הביא תועלת מרובה כפי שניתן היה לחשוב בתחילת העבודה.
אין לי גישה של "אוהב" או "לא אוהב" יוניט-טסטים, אני עושה את זה אם צריך, והתייחסתי רבות לצורך בבדיקות-יחידה בהתאם לגודל הפרוייקט והשלב בו הוא נמצא, ומספר האנשים שמעורבים בו. כרגע למשל אני חלק מפרוייקט שבו משתמשים בהן, ולכן אני מממש בדיקות שכאלה, ולפני שבוע העברתי קומיט של קוד לאחר שהעברתי אותו דרך משהו כמו 100 בדיקות שונות, ולאחר שעבר את כולן בהצלחה, רק ששכחתי להריץ את הפרוייקט, ורגע אחרי שעשיתי PUSH גיליתי שהפרוייקט לא עולה בכלל (מסתבר שזה בגלל attribute שהיה חסר - DataContract). אני לא בא לומר שאלה או אלה לבדם הם חיוניים, אלא שיש להשתמש גם באלה וגם באלה בצורה מדודה.
אני *כן* משתמש (לפחות בפרוייקט הנוכחי) ב-IoC - וגם פה יש הרבה מאד יתרונות והרבה מאד בעיות. לדוגמה קטנה מהקטנות, אם דברים לא עובדים כמצופה, יש הרבה יותר קושי למצוא למה, מאשר בדרך שבה אני הוא היוצר את האובייקטים. עבדתי במספר פרוייקטים שבהם עשו שימוש ב-DI/IoC שבעצם לא הביא הרבה תועלת, אבל מצד שני יצר המון קשיים, ולכן הגישה שלי היא פרקטית, כלומר מה שעובר ומה שעוזר זה מה שצריך לעשות. באחד המקומות שבהם עבדתי והיה שם את השימוש המאסיבי ביותר גם בבדיקות וגם ב-DI הקצב של התקדמות הפיתוח היה איטי עד אפסי, ובדיעבד חלק גדול מזה נגרם מהשימוש (חלקו לקוי) בשיטות אלה. אלה שיטות שקל מאד לעשות להן abuse וקשה מאד להבין איך בדיוק צריך לעבוד איתן והיכן כן והיכן לא, ובמקום שבנאדם ישב וילמד אלף דברים בשביל אפליקציה של ספר טלפונים, ההמלצה שלי היא פשוט לכתוב את התוכנה כך שתציג ספר טלפונים. אם בשלב מאוחר יותר ספר-הטלפונים הופך למערכת CRM רב-שכבתית, יהיה בכל מקרה צורך לשנות את הארכיטקטורה מתחילתה ועד סופה, ובין השאר כנראה יהיה צורך להכניס IOC או DI ובדיקות-יחידה.
מעולם לא טענתי שאין צורך להפריד את שכבת ה-VIEW משכבת VM, טענתי (אם זכרונני איננו מטעני) שלגבי MODEL ו-VM, לרוב המימוש של שכבת המודל הוא בעזרת ORM כלשהו, וזה ממומש ע"י EF ודומיו, שגם דואג לממש נוטיפיקציות על שינוי, ולכן אין באמת שכבת מודל שצריך לטרוח עליה כמו על שכבת ה-VM. בנוסף אמרתי שלפעמים הדרך הכי מוצלחת היא להשתמש ב-VIEW ובקוד שלו ע"מ לבצע משימה, אני לא חושב שזו הדרך המיטבית אבל כמו תמיד אם בהמשך מתגלה בעיה, עושים refactoring ומשנים את מבנה הקוד.
הטענה העיקרית שלי היא שצריך להיות כל הזמן הם העיניים על המטרה, ולא עם העיניים תקועות בספר של איך נכון לעבוד, כי יש המון שיטות נכונות לעבוד, ולא תמיד כולן מסייעות למוצר או למתכנת או ללקוח, אלא בעיקר למי שכתב את הספר. מה שעובד, ברוך הבא, מה שלא עובד, הראו לו את הדלת.
הדעה שלי לגבי פריזם לא נסמכת אך ורק על ניסיוני עם סביבה זו, אלא בעיקר על פרויקטים שראיתי שמומשו בפרוייקטים שהגעתי אליהם לאחר שכבר היו בנויים זמן רב, ובעיקר משיחות שהיו לי עם אנשים נוספים שאני מעריך את דעתם בנוגע לסביבה הזו, וגם דעתם לא הייתה נוחה מהשימוש המורכב מאד באופן יחסי בסביבה זו.
בברכה,
זיו
אני מברך על ההסכמה החלקית 
אדרבה, אמור לנו מה MVVM נותן לך, חוץ מBinding.
MVVM הוא תבנית עיצוב, שנבנה [כמו רוב התבניות] כדי להשתלב עם תבניות אחרות. יוניטטסטים, זו לא מטרה משנית, אלא מטרה ראשית ומוצהרת של MVVM. ובשביל זה, אתה חייב DI [עם קונטיינר או בלעדיו], וגם אסור לך להתייחס לView מתוך הViewModel.
אני מתייחס לעצה שנתת לי בתחילת דרכי, בדיון הזה. ['כלליים' זה ניקי הקודם]
שם כתבת שהפרדת הView היא אמירה פומפוזית שאין מאחוריה דבר, שאינך עובד עם יוניטטסטים והיתרונות שלהם באים לידי ביטוי רק בצוותים גדולים עם 5-8 מפתחים וכו'.
אכן שמעתי לעצתך, והלכתי על MVVMLight. אבל בויכוח בינך לבין לורן בוגניון על IOC, העדפתי את בוגניון. קצת רספקט למפתח של MvvnLight
אגב, הטענות שהשמעת כלפי DI/IOC דומות להפליא לטענותיך כלפי פריזם.
מפריזם התרחקתי כעצתך, אבל עם הזמן MvvmLight כבר לא ענה על האתגרים, בעיקר כי הוא נותן מענה רק לשכבת ViewModel. אבל מה עם ניהול הUI? שהלך והתסבך ככל שהפרוייקט התקדם? MvvmLight איננו נותן שום תבנית לניהול UI.
ואז בדיוק יצא פריזם 5, שלהבדיל מגרסאות קודמות הוא מפוצל ומודולרי. ניסיתי את Prism.Mvvm שהוא תאום לMvvmLight, אחר כך את הקונטיינר [MEF] ובהדרגה הטמעתי עוד ועוד רעיונות פריזמאיים לתוך הפרוייקטים שלי, והיום אני מסתדר עימם להפליא ובקלות רבה.
אדרבה, אמור לנו מה MVVM נותן לך, חוץ מBinding.
MVVM הוא תבנית עיצוב, שנבנה [כמו רוב התבניות] כדי להשתלב עם תבניות אחרות. יוניטטסטים, זו לא מטרה משנית, אלא מטרה ראשית ומוצהרת של MVVM. ובשביל זה, אתה חייב DI [עם קונטיינר או בלעדיו], וגם אסור לך להתייחס לView מתוך הViewModel.
אני מתייחס לעצה שנתת לי בתחילת דרכי, בדיון הזה. ['כלליים' זה ניקי הקודם]
שם כתבת שהפרדת הView היא אמירה פומפוזית שאין מאחוריה דבר, שאינך עובד עם יוניטטסטים והיתרונות שלהם באים לידי ביטוי רק בצוותים גדולים עם 5-8 מפתחים וכו'.
אכן שמעתי לעצתך, והלכתי על MVVMLight. אבל בויכוח בינך לבין לורן בוגניון על IOC, העדפתי את בוגניון. קצת רספקט למפתח של MvvnLight
אגב, הטענות שהשמעת כלפי DI/IOC דומות להפליא לטענותיך כלפי פריזם.
מפריזם התרחקתי כעצתך, אבל עם הזמן MvvmLight כבר לא ענה על האתגרים, בעיקר כי הוא נותן מענה רק לשכבת ViewModel. אבל מה עם ניהול הUI? שהלך והתסבך ככל שהפרוייקט התקדם? MvvmLight איננו נותן שום תבנית לניהול UI.
ואז בדיוק יצא פריזם 5, שלהבדיל מגרסאות קודמות הוא מפוצל ומודולרי. ניסיתי את Prism.Mvvm שהוא תאום לMvvmLight, אחר כך את הקונטיינר [MEF] ובהדרגה הטמעתי עוד ועוד רעיונות פריזמאיים לתוך הפרוייקטים שלי, והיום אני מסתדר עימם להפליא ובקלות רבה.
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.