איך בוחרים בין WinForms,‏ WPF ו-WinUI - טבלת החלטה מהשטח

קהל היעד: מפתחים שבונים יישומי שולחן עבודה ל-Windows ב-C#‏/‏.NET, ומי שקובע את הבחירה הטכנולוגית. הנחת יסוד: משתמשים ב-‏.NET הנוכחי (לא ב-.NET Framework), ופלטפורמת היעד היא Windows בלבד. איך לקרוא: אם רוצים רק את המסקנה, קראו פרקים 1 ו-3; אם רוצים לקבוע מדיניות הארכת חיים ליישום קיים, קראו פרק 7; אם רוצים את ההכרעה האחרונה, קראו פרק 8.

כשבונים יישום שולחן עבודה ל-Windows ב-C#‏/‏.NET, מה שמסתבך בכל פעם מחדש בלי רעש הוא הבחירה בין WinForms,‏ WPF ו-WinUI.

הדבר המסוכן כאן הוא בחירה מעורפלת כמו:

• WinUI כי הוא הכי חדש
• WinForms כי אליו הכי רגילים
• WPF כי הוא נראה איפשהו באמצע

flowchart TB
    accTitle: הסכנה שבבחירה מעורפלת
    accDescr: תרשים המראה שבחירה מעורפלת כמו WinUI כי הוא חדש, WinForms כי אליו רגילים, ו-WPF כי הוא נראה באמצע, מסוכנת, ושבעבודה בפועל בוחנים לפי צירים ברורים יותר.
    w1["WinUI כי הוא חדש"] --> w4["בחירה מעורפלת"]
    w2["WinForms כי אליו רגילים"] --> w4
    w3["WPF כי הוא נראה באמצע"] --> w4
    w4 --> w5["בעבודה בפועל בוחנים לפי צירים ברורים"]

איור 1: לא “חדש, מוכר או נראה באמצע” - בוחרים לפי צירים ברורים.

בעבודה בפועל, הצירים שצריך לבחון קצת יותר ברורים:

• פיתוח חדש, או המשך של נכס קיים
• האם המסך מבוסס טופסי קלט, או דורש כוח ביטוי
• האם UI מודרני ואופייני ל-Windows הוא ערך המוצר עצמו
• איך מטפלים בהפצה, עדכון והפעלה ארגונית
• האם הצוות שייך לתרבות ה-Designer, או לתרבות XAML‏/‏MVVM

במאמר הזה נסדר את כל זה בטבלת החלטה אחת נוחה לצפייה. לצורך המאמר, WinUI מתייחס בעיקר ל-WinUI 3 + Windows App SDK.¹²

בנוסף, שלושתם ייעודיים כולם ל-Windows בלבד. אם macOS‏/‏Linux גם הם בתמונה, מדובר מלכתחילה בהגדרת בעיה אחרת.³⁴¹

flowchart TB
    accTitle: שלושתם ייעודיים ל-Windows בלבד
    accDescr: תרשים המראה ש-WinForms, WPF ו-WinUI כולם ייעודיים ל-Windows בלבד, ושאם macOS או Linux גם הם בתמונה, מדובר בהגדרת בעיה אחרת לגמרי.
    t1["WinForms"] --> t4["כולם ייעודיים ל-Windows"]
    t2["WPF"] --> t4
    t3["WinUI"] --> t4
    t4 -.-> t5["macOS / Linux - הגדרת בעיה אחרת"]

איור 2: שלושתם ייעודיים ל-Windows, ופלטפורמות חוצות דורשות הגדרת בעיה אחרת.

1. המסקנה קודם (במשפט אחד)

בניסוח גס אבל שימושי בעבודה בפועל, הנה זה:

• אם יש יישום WinForms קיים גדול, קודם כול בוחנים המשך עם WinForms
• אם יש יישום WPF קיים גדול, קודם כול בוחנים המשך עם WPF
• לכלי פנים-ארגוני חדש בקנה מידה קטן-בינוני, שמבוסס על פקדים סטנדרטיים ומסכי קלט ורוצים לבנות מהר, WinForms עדיין די חזק³⁵
• ליישום עסקי חדש בקנה מידה בינוני-גדול, עם הרבה מסכים, שרוצים לנצל בו כראוי data binding,‏ style,‏ template,‏ command ו-MVVM, WPF לרוב הבחירה הבטוחה ביותר⁴⁶⁷
• למוצר חדש ייעודי ל-Windows, שבו UI מודרני של Windows,‏ Fluent וחוויית Windows עדכנית קשורים ישירות לערך המוצר, WinUI אפשרות טובה¹²
• אם רוצים רק להשתמש בפיצ’רי Windows API עדכניים, WinUI אינו הכרחי. גם WPF‏/‏WinForms יכולים לשלב פיצ’רים של Windows App SDK²⁸⁹¹⁰
• לבחור על סמך הנחה של “אפשר להכניס WinUI בהדרגה בהמשך” מסוכן במקצת. סיפור המעבר ההדרגתי מלוכלך יותר ממה שנדמה¹⁰¹¹

בקיצור, זה בערך כך:

1. אם יש נכסים קיימים גדולים, קודם כול משמרים את אותו קו
2. בפיתוח חדש, לבניית טפסים סטנדרטיים מהר - WinForms
3. בפיתוח חדש, ליישום עסקי ל-Windows שגדל לאורך זמן - WPF
4. בפיתוח חדש, כש-UI מודרני של Windows הוא עצמו דרישה - WinUI
5. אם רוצים רק Windows App SDK, לא עוברים ישר לגמרי ל-WinUI

בחירת framework היא לא רק בחירה בטכנולוגיית UI, אלא גם בחירה של הפצה, תפעול, עלות למידה ועלות מעבר. אם קובעים את זה רק לפי “חדש / ישן”, זה חוזר בהמשך כתכנון הפצה ועלות תחזוקה.

flowchart TB
    accTitle: איך מגיעים למסקנה
    accDescr: תרשים המראה שאם יש נכסים קיימים גדולים משמרים את אותו קו, ובפיתוח חדש בוחרים WinForms לטפסים סטנדרטיים, WPF ליישום עסקי שגדל לאורך זמן, ו-WinUI כש-UI מודרני הוא דרישה.
    r1{"האם יש נכסים קיימים גדולים"} -->|"כן"| r2["משמרים את אותו קו"]
    r1 -->|"לא, פיתוח חדש"| r3{"מבוסס טפסים סטנדרטיים"}
    r3 -->|"כן"| r4["WinForms"]
    r3 -->|"לא"| r5{"UI מודרני הוא דרישה"}
    r5 -->|"לא"| r6["WPF - יישום עסקי ארוך טווח"]
    r5 -->|"כן"| r7["WinUI"]
    r7 -.-> r8["אם רק SDK - לא עוברים לגמרי ל-WinUI"]

איור 3: לפי סדר נכסים קיימים, אופי המסך ודרישת UI מודרני, המסקנה כמעט נקבעת מאליה.

מפת הידע של המאמר

המאמר מסדר איך בוחרים בין WinForms,‏ WPF ו-WinUI לפי הציר של פיתוח חדש מול המשך נכסים קיימים, והאם המסך מבוסס טפסים סטנדרטיים או דורש כוח ביטוי. הוא ממליץ על WinForms ליישום עסקי המבוסס על פקדים סטנדרטיים, על WPF ליישום עסקי בינוני-גדול שמנצל data binding ו-MVVM, ועל WinUI למוצר חדש ייעודי ל-Windows שבו Fluent וחוויית Windows עדכנית קשורים ישירות לערך המוצר. ‏WinUI הוא חלק ה-UI framework בתוך Windows App SDK, ומניח כברירת מחדל חבילת MSIX ו-package identity, בעוד Windows App SDK עצמו אפשר להוסיף גם לנכסי WPF/WinForms קיימים - ולכן מעבר מלא של ה-UI אינו הכרחי. המאמר מזהיר שמעבר הדרגתי בעזרת XAML Islands צריך להיבדק בקטן לפני שהופך לאסטרטגיה הראשית.

flowchart LR
    accTitle: מפת הידע של איך בוחרים בין WinForms,‏ WPF ו-WinUI
    accDescr: תרשים המראה את הציר שלפיו WinForms,‏ WPF ו-WinUI מתאימים לפיתוח חדש או להמשך נכסים קיימים, את ההנחה של WinUI לגבי Windows App SDK,‏ MSIX ו-package identity, את הקשר בין MVVM ל-data binding, ואת נקודת הזהירות סביב מעבר הדרגתי עם XAML Islands.
    windows_forms["Windows Forms"]
    wpf["WPF"]
    winui["WinUI(Windows App SDK)"]
    xaml["XAML"]
    data_binding["קישור נתונים (data binding)"]
    mvvm_pattern["MVVM(Model-View-ViewModel)"]
    windows_app_sdk["Windows App SDK"]
    msix["MSIX"]
    package_identity["package identity"]
    sparse_package["‏packaged שמצביע על מיקום חיצוני (sparse package)"]
    unpackaged_app["unpackaged app"]
    xaml_islands["XAML Islands"]
    gradual_winui_migration["מעבר הדרגתי ל-WinUI מתוך WPF/WinForms קיימים"]
    standard_control_centric_app["יישום עסקי המבוסס על פקדים סטנדרטיים"]
    multi_screen_business_app["יישום עסקי בינוני עד גדול עם מסכים רבים"]
    windows_native_modern_product["ממשק מוצר מודרני חדש ייעודי ל-Windows"]
    fluent_design["Fluent Design System"]
    wpf -->|"משתמש ב"| xaml
    winui -->|"משתמש ב"| xaml
    wpf -->|"משתמש ב"| data_binding
    mvvm_pattern -->|"מחייב"| data_binding
    wpf -.->|"משתמש ב"| mvvm_pattern
    winui -.->|"משתמש ב"| mvvm_pattern
    winui -->|"מממש את"| windows_app_sdk
    wpf -.->|"משתמש ב"| windows_app_sdk
    windows_forms -.->|"משתמש ב"| windows_app_sdk
    winui -.->|"מחייב"| msix
    msix -->|"מחייב"| package_identity
    sparse_package -->|"מחייב"| package_identity
    unpackaged_app -->|"אינו מתיישב עם"| package_identity
    wpf -.->|"משתמש ב"| xaml_islands
    windows_forms -.->|"משתמש ב"| xaml_islands
    gradual_winui_migration -->|"מחייב"| xaml_islands
    gradual_winui_migration -->|"שימוש לא מומלץ ל"| winui
    windows_forms -->|"מענה מומלץ ל"| standard_control_centric_app
    wpf -->|"מענה מומלץ ל"| multi_screen_business_app
    winui -->|"מענה מומלץ ל"| windows_native_modern_product
    windows_forms -->|"צריך לקדום ל"| winui
    wpf -->|"צריך לקדום ל"| winui
    windows_app_sdk -->|"צריך לקדום ל"| winui
    winui -->|"משתמש ב"| fluent_design

בתרשים, קו מלא מציין קשר שמתקיים תמיד וקו מקווקו מציין קשר מותנה (תנאי ההתקיימות מפורטים בהסבר של כל קשר בעמוד המפורט). רשימת כל הקשרים (סך הכול 24, עם אסמכתה ורמת ודאות) והגדרות המושגים המרכזיים מרוכזות בעמוד המפורט של מפת הידע (ביפנית). נתונים: JSON-LD / Turtle

2. שלוש הטכנולוגיות שהמאמר מתייחס אליהן

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

‏WinForms מתואר גם ב-Microsoft Learn כ-framework עם פקדים, גרפיקה, data binding וקלט משתמש, שקל לבנות בו אפליקציה בעזרת ה-Designer של Visual Studio בגרירה-ושחרור.³

‏WPF הוא framework‏ UI בעל כוח ביטוי גבוה, הכולל ציור וקטורי בלתי-תלוי ברזולוציה,‏ XAML,‏ data binding,‏ style‏/‏template,‏ 2D‏/‏3D ואנימציה.⁴

‏WinUI, חלק מ-Windows App SDK, הוא framework‏ UI עדכני ל-Windows שמניח DPI גבוה, קלט מודרני, אנימציה חלקה וחוויית Fluent.¹² יש לו גם מסלול רגיל של data binding‏/‏MVVM.¹²

חשוב לזכור כאן ש-Windows App SDK ו-WinUI אינם אותו דבר. ‏WinUI הוא חלק ה-UI‏ framework בתוך Windows App SDK, אבל את Windows App SDK עצמו אפשר להוסיף גם ליישומים קיימים של WPF‏/‏WinForms‏/‏Win32.²¹⁰

לכן,

• להשתמש ב-WinUI
• להשתמש בפיצ’רים של Windows App SDK

הן החלטות דומות במראה, אבל נפרדות. אם דנים בזה כשהן מעורבבות, “האם להעביר את ה-UI” ו”האם להוסיף פיצ’רים” נדונים כאותו נושא, וקשה להגיע למסקנה.

flowchart TB
    accTitle: Windows App SDK ו-WinUI אינם זהים
    accDescr: תרשים המראה ש-WinUI הוא חלק ה-UI framework בתוך Windows App SDK, ושאת Windows App SDK עצמו אפשר להוסיף גם ל-WPF, WinForms ו-Win32, ולכן ההחלטה על WinUI וההחלטה על פיצ'רי SDK נפרדות.
    sdk["Windows App SDK"] --> ui["WinUI - חלק ה-UI framework"]
    sdk -.-> ex["ניתן להוסיף ל-WPF/WinForms/Win32"]
    ui --> d1["החלטה: 'להשתמש ב-WinUI'"]
    ex --> d2["החלטה: 'להשתמש בפיצ'רי SDK'"]
    d1 --> d3["דומות אך נפרדות"]
    d2 --> d3

איור 4: “להשתמש ב-WinUI” ו”להשתמש בפיצ’רים של Windows App SDK” הן החלטות נפרדות.

3. טבלת החלטה אחת לצפייה

קודם כול, הטבלה הכי שימושית לעבודה בפועל.

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

1. ביישום עסקי חדש ל-Windows, לאיזה מבין WinForms ו-WPF להתקרב
2. כשיש WPF‏/‏WinForms קיימים, האם כדאי לעבור ל-WinUI

שתי הנקודות האלה קל יותר להכריע בהן תוך התבוננות בטבלת ההשוואה שבהמשך.

flowchart TB
    accTitle: שתי הנקודות שנשארות אחרי טבלת ההחלטה
    accDescr: תרשים המראה שגם עם טבלת החלטה אחת נשארות שתי שאלות - האם ליישום עסקי חדש להתקרב ל-WinForms או WPF, והאם לעבור ל-WinUI כשיש נכסים קיימים - וששתיהן נבחנות בטבלת ההשוואה הבאה.
    hyo["טבלת ההחלטה"] --> n1["WinForms או WPF ליישום חדש"]
    hyo --> n2["האם לעבור ל-WinUI כשיש נכסים קיימים"]
    n1 --> hik["בוחנים בטבלת ההשוואה"]
    n2 --> hik

איור 5: שתי הנקודות שנשארות אחרי הטבלה נבחנות בטבלת ההשוואה שבהמשך.

4. טבלת השוואה לפי היבטים

זו לא טבלת עליונות רשמית, אלא השוואה מוטה מאוד לעבודה בפועל.

הטריק בקריאה הוא לא מה הכי חזק, אלא מה הכי מעט מחכך.

לדוגמה, עבור:

• כלי הגדרות פנים-ארגוני
• מסך הגדרות מכשיר
• רשימה, פירוט, חיפוש, הגדרות, כפתורים
• יציבות תפעולית ומהירות שיפוץ חשובים יותר מהמראה

‏WinForms עדיין הגיוני לגמרי.

לעומת זאת, עבור:

• הרבה מסכים
• הרבה החלפות מצב תצוגה
• רוצים להפריד בין View ללוגיקה
• רוצים לקשר שינויי נתונים ל-UI בטבעיות
• רוצים לשלוט ב-UI דרך style/template

‏WPF עובד היטב.⁶⁷

ולבסוף, עבור:

• רוצים להניח מראה אופייני ל-Windows 11
• רוצים לנצל את Fluent כראוי
• רוצים להניח DPI גבוה, מגע, ו-API חלונות מודרני
• פיתוח חדש שבו הרושם של ה-UI כמוצר ייעודי ל-Windows חשוב

‏WinUI טבעי.¹²

flowchart TB
    accTitle: בוחרים לפי כמות החיכוך הנמוכה ביותר
    accDescr: תרשים המראה שהקריטריון הוא לא מה הכי חזק אלא מה הכי מעט מחכך, וש-WinForms טבעי לכלי פנים-ארגוני מבוסס פקדים, WPF להרבה מסכים עם MVVM, ו-WinUI כש-Fluent וחוויית Windows עדכנית הם הבסיס.
    k0["מה הכי מעט מחכך"] --> k1["כלי ארגוני - פקדים סטנדרטיים"]
    k0 --> k2["הרבה מסכים - רוצים MVVM"]
    k0 --> k3["Fluent - חוויית Windows עדכנית"]
    k1 --> k4["WinForms"]
    k2 --> k5["WPF"]
    k3 --> k6["WinUI"]

איור 6: לא “מה הכי חזק” אלא “מה הכי מעט מחכך” - כך מחלקים בין השלושה.

4.1 לראות את “הפער בכוח הביטוי” בקוד מינימלי

השורה “התאמה ל-data binding‏/‏MVVM” בטבלה למעלה קשה לתפוס במילים בלבד. לכן נציג זה לצד זה, בקוד מינימלי, מה משתנה כשכותבים את אותו מסך ב-WinForms וב-WPF.

נבנה מסך עם “תיבת טקסט אחת וכפתור שמירה אחד” בלבד.

WinForms: ה-Designer מייצר *.Designer.cs, וב-event handler שולפים את הערך מהמסך.

// MainForm.Designer.cs — הצד שמייצר ה-Designer. לא כותבים כאן ידנית
private System.Windows.Forms.TextBox nameTextBox;
private System.Windows.Forms.Button saveButton;

private void InitializeComponent()
{
    this.nameTextBox = new System.Windows.Forms.TextBox();
    this.saveButton = new System.Windows.Forms.Button();
    this.SuspendLayout();

    this.nameTextBox.Location = new System.Drawing.Point(12, 12);
    this.nameTextBox.Size = new System.Drawing.Size(200, 23);

    this.saveButton.Location = new System.Drawing.Point(218, 12);
    this.saveButton.Size = new System.Drawing.Size(75, 23);
    this.saveButton.Text = "保存";
    this.saveButton.Click += new System.EventHandler(this.SaveButton_Click);

    this.Controls.Add(this.nameTextBox);
    this.Controls.Add(this.saveButton);
    this.ResumeLayout(false);
}

// MainForm.cs — הצד שכותבים ידנית
public partial class MainForm : Form
{
    private readonly EditorService _service;

    public MainForm(EditorService service)
    {
        _service = service;
        InitializeComponent();
    }

    private void SaveButton_Click(object sender, EventArgs e)
    {
        // שולפים את הערך ישירות מהפקד של המסך ומעבירים אותו
        _service.Save(this.nameTextBox.Text);
    }
}

WPF: ב-XAML כותבים רק “עם מה זה מחובר”, וה-Binding מטפל בהכנסה ובהוצאה של הערך.

<!-- MainWindow.xaml -->
<Window x:Class="MyApp.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="編集" Width="360" Height="120">
    <StackPanel Orientation="Horizontal" Margin="12">
        <TextBox Width="200"
                 Text="{Binding Name, UpdateSourceTrigger=PropertyChanged}" />
        <Button Width="75" Margin="6,0,0,0" Content="保存"
                Command="{Binding SaveCommand}" />
    </StackPanel>
</Window>

// MainWindow.xaml.cs — אם שוכחים להעביר DataContext, ה-Binding לא עושה כלום
public partial class MainWindow : Window
{
    public MainWindow(EditorService service)
    {
        InitializeComponent();
        this.DataContext = new MainViewModel(service);
    }
}

// MainViewModel.cs — הצד שלא מכיר את המסך. אפשר לכתוב כאן גם unit test
public sealed class MainViewModel : INotifyPropertyChanged
{
    private readonly EditorService _service;
    private string _name = string.Empty;

    public MainViewModel(EditorService service)
    {
        _service = service;
        SaveCommand = new RelayCommand(() => _service.Save(Name));
    }

    public string Name
    {
        get => _name;
        set
        {
            if (_name == value) return;
            _name = value;
            PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(Name)));
        }
    }

    public ICommand SaveCommand { get; }

    public event PropertyChangedEventHandler PropertyChanged;
}

‏RelayCommand הוא class קטן שמממש ICommand, נמצא גם בספריות כמו CommunityToolkit.Mvvm, וגם אפשר לכתוב אותו בעצמכם בכ-20 שורות.

אם סופרים רק שורות, ל-WPF יש יותר. ההבדל האמיתי מתחיל מכאן.

אם יש 3 מסכים, WinForms מהיר יותר; אם יש 30 מסכים, WPF קליל יותר - זו המשמעות המעשית של ההבדל.

flowchart TB
    accTitle: ההבדל בזרימת הערך
    accDescr: תרשים המראה שב-WinForms ה-event handler שולף ערך ישירות מהפקד ומעביר לשירות, ואילו ב-WPF ה-Binding מחבר בין ה-View ל-ViewModel, וה-ViewModel שלא מכיר את המסך קורא לשירות.
    subgraph wf["WinForms"]
    a1["פקד ב-View"] --> a2["event handler"]
    a2 --> a3["קורא ישירות לשירות"]
    end
    subgraph wp["WPF"]
    b1["XAML של ה-View"] --> b2["Binding"]
    b2 --> b3["ViewModel"]
    b3 --> b4["קורא לשירות"]
    end
    a3 -.-> c1["3 מסכים - מהיר"]
    b4 -.-> c2["30 מסכים - עדיין קליל"]

איור 7: ב-WinForms שולפים ערך ישירות, וב-WPF ה-Binding מעביר את התפקיד ל-ViewModel.

5. לאיזה סוג פרויקט כל אחד מתאים

5.1 WinForms

‏WinForms נוטה לזכות בזלזול לא הוגן, אבל בנקודה אחת - בניית מסכים עסקיים מהירה, מבוססת פקדים סטנדרטיים - הוא עדיין לא זניח.³⁵

הוא מתאים במיוחד לפרויקטים כמו:

• כלי הגדרות פנים-ארגוני
• מסכי הגדרות למכשירים, מכשירי מדידה וכלי ניטור
• מסכי ניהול, מסכי חיפוש, רשימה + פירוט
• פרויקטים עם נכסי WinForms קיימים גדולים
• צוותים עם תרבות חזקה של בניית מסכים ב-Designer

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

עם זאת, החולשות ברורות:

• רוצים אחידות מראה גדולה בכל המסכים
• רוצים לשלוט ב-UI דרך style ו-template
• רוצים לטפל בשינויי מצב מורכבים בעיקר דרך data binding
• רוצים להפריד יפה את הלוגיקה של המסך

בנקודות האלה, WPF או WinUI פשוטים יותר.

בבניית יישום גדול עם WinForms, בלי תשומת לב זה בקלות הופך לג’ונגל של event handlers. לכן, אם בוחרים ב-WinForms, כדאי לקבוע מראש לפחות:

• לשמור על אחריות קטנה לכל מסך
• להפריד ביחידות UserControl
• להיות מודעים לגבול מקביל ל-Presenter‏/‏ViewModel
• לא לכתוב לוגיקה עסקית ישירות בתוך אירועי המסך

flowchart TB
    accTitle: להימנע מג'ונגל event handlers
    accDescr: תרשים המראה שיישום WinForms גדול הופך בקלות לג'ונגל של event handlers, ולכן כדאי לקבוע מראש לשמור על אחריות קטנה למסך, להפריד ביחידות UserControl, ולהיות מודעים לגבול Presenter/ViewModel.
    mo["יישום WinForms גדול"] --> ha["הופך בקלות לג'ונגל handlers"]
    ha --> p1["לשמור אחריות קטנה למסך"]
    ha --> p2["להפריד ביחידות UserControl"]
    ha --> p3["להיות מודעים לגבול"]
    p3 -.-> p4["לא לכתוב לוגיקה עסקית באירועי מסך"]

איור 8: יישום WinForms גדול נשאר שקט אם קובעים מראש כללי הפרדת אחריות.

עוד דבר חשוב מאוד בעבודה בפועל: גם אם רוצים להשתמש ב-Windows App SDK, אין צורך לזרוק את WinForms. גם רשמית קיים מסלול להוסיף פיצ’רי Windows App SDK ליישום WinForms קיים.⁹¹⁰

כלומר, אפשר לבחור ב-WinForms כך ש-

• ה-UI נשאר כמות שהוא
• רק פיצ’רי Windows הדרושים מתמדרנים

וזה נקודת נחיתה ריאלית.

flowchart TB
    accTitle: לתמדרן בלי לזרוק את WinForms
    accDescr: תרשים המראה שהרצון להשתמש ב-Windows App SDK אינו מחייב לזרוק את WinForms, ושיש נקודת נחיתה ריאלית שבה ה-UI נשאר כמות שהוא ורק הפיצ'רים הדרושים מתמדרנים.
    g1["רוצים Windows App SDK"] --> g2["אין צורך לזרוק WinForms"]
    g2 --> g3["ה-UI נשאר כמות שהוא"]
    g2 --> g4["מתמדרנים רק הפיצ'רים הדרושים"]
    g3 --> g5["נקודת נחיתה ריאלית"]
    g4 --> g5

איור 9: אפשר לשמר את ה-UI של WinForms ולתמדרן רק את הפיצ’רים הדרושים של Windows.

5.2 WPF

‏WPF, כשמסתכלים עליו כ-UI‏‏ ‏.NET לשולחן העבודה של Windows, הוא הליבה המאוזנת ביותר.⁴

היתרונות ברורים:

• אפשר לכתוב מסך הצהרתית ב-XAML
• ‏Data Binding חזק
• אפשר להשתמש ב-Style‏/‏Template
• אפשר להשתמש ב-Command
• קל להפריד בין View ללוגיקה
• קל לסדר מסכים בקנה מידה בינוני-גדול

גם בתיעוד הרשמי של WPF, data binding מתואר כפיצ’ר מרכזי, וה-command מסודר כמנגנון שמפריד בין קלט ללוגיקת הביצוע.⁶⁷

לכן, הוא מתאים לפרויקטים כמו:

• יישום עסקי עם הרבה מסכים
• הרבה תצוגות רשימה, פירוט, עריכה, חיפוש ומצב
• יישום Windows שכמה אנשים מתחזקים לאורך זמן
• רוצים להפריד בין View ללוגיקה
• רוצים להפריד מראש בין אחריות המראה לאחריות ההתנהגות, לקראת שיפוצים עתידיים
• ‏WinForms נראה כמו שיהפוך למסך כבד מהר

כשמתלבטים ביישום עסקי חדש ייעודי ל-Windows, ‏WPF עדיין המועמד הראשון הבטוח. לפסול אותו כי “הוא ישן” זה קצת גס.

flowchart TB
    accTitle: המועמד הראשון הבטוח ליישום עסקי חדש
    accDescr: תרשים המראה שביישום עסקי בינוני-גדול ל-Windows עם הרבה מסכים, שרוצים להפריד View מלוגיקה ומתוחזק לאורך זמן על ידי כמה אנשים, WPF עדיין המועמד הראשון הבטוח.
    j1["יישום עסקי עם הרבה מסכים"] --> j4["WPF - המועמד הראשון הבטוח"]
    j2["רוצים להפריד View מלוגיקה"] --> j4
    j3["תחזוקה ארוכת טווח על ידי כמה אנשים"] --> j4
    j4 -.-> j5["לפסול כי 'ישן' זה גס"]

איור 10: ביישום עסקי חדש עם הרבה מסכים ותחזוקה ארוכת טווח, WPF עדיין הבחירה הבטוחה.

ולמעשה, כש-

• יש נכסי WPF קיימים
• יש ידע קיים ב-XAML‏/‏MVVM
• לא ‏Fluent הוא הראשון בעדיפות
• אבל רוצים לתכנן UI יפה יותר מ-WinForms

‏WPF לרוב הבחירה ההגיונית ביותר.

כמובן שגם ל-WPF יש מוזרויות:

• ‏XAML מסובך מדי הופך לקשה לקריאה
• יותר מדי פקדים או תבניות מותאמות אישית מכבידים על התחזוקה
• מדיניות “לפתור הכול עם Binding” יכולה להקשות דווקא על מעקב אחר זרימת העיבוד

הבעיות האלה קיימות, אבל זה לא ש-WPF רע - זה יותר שכלי בעל כוח ביטוי, אם משתמשים בו ברשלנות, גם התגובה שלו חזקה יותר.

גם ב-WPF אפשר להוסיף חלק מהפיצ’רים של Windows App SDK. כלומר, יש דרך לתמדרן פיצ’רי Windows בזמן שנשארים עם WPF.⁸¹⁰

לכן, לרוב, בעבודה בפועל מנצחת הגישה של

• להתקרב ל-‏.NET הנוכחי עם WPF
• להוסיף רק את פיצ’רי Windows הדרושים דרך Windows App SDK
• לסדר מחדש את המבנה החל מהפיצ’רים הגדולים החדשים

יותר מ-

• לזרוק את כל ה-WPF ולעבור לגמרי ל-WinUI

flowchart TB
    accTitle: הדרגתיות מנצחת מעבר מלא
    accDescr: תרשים המראה שבמקום לזרוק את WPF ולעבור לגמרי ל-WinUI, עדיף להתקרב ל-.NET הנוכחי, להוסיף רק פיצ'רים דרושים דרך Windows App SDK, ולסדר מחדש החל מהפיצ'רים הגדולים החדשים.
    z1["WPF מתקרב ל-.NET הנוכחי"] --> z2["מוסיפים רק פיצ'רים דרושים דרך SDK"]
    z2 --> z3["מסדרים מחדש מהפיצ'רים הגדולים החדשים"]
    z3 -.-> z4["מנצח לרוב מעל מעבר מלא"]

איור 11: במקום מעבר מלא, להתקרב ל-‏.NET הנוכחי ולהוסיף פיצ’רים בהדרגה - זו הדרך שמנצחת יותר.

5.3 WinUI

‏WinUI הוא הבחירה המודרנית העיקרית לבניית יישום חדש ייעודי ל-Windows.¹²

באופן רשמי הוא ממוקם כך:

• מותאם לחומרה ולקלט העדכניים ביותר
• ‏DPI גבוה
• אנימציה חלקה
• חלק מ-Windows App SDK

¹

לכן הוא מתאים לפרויקטים כמו:

• מוצר חדש ייעודי ל-Windows
• הרושם או החוויה של ה-UI עצמם חשובים
• רוצים לנצל את Fluent בטבעיות
• רוצים להתקרב למצב הנוכחי של Windows 11
• רוצים להניח API חלונות חדש וחוויית Windows עדכנית

פרויקט שיש בו סיבה אמיתית לבחור ב-WinUI הוא לרוב לא פרויקט של “המראה חדש”, אלא של “רוצים לשלב את חוויית ה-Windows הנוכחית במוצר”.

flowchart TB
    accTitle: איך מזהים סיבה אמיתית לבחור ב-WinUI
    accDescr: תרשים המראה שפרויקט עם סיבה אמיתית לבחור ב-WinUI הוא לא "המראה חדש" אלא "רוצים לשלב את חוויית ה-Windows הנוכחית במוצר" - מוצר חדש ייעודי ל-Windows שבו הרושם של ה-UI חשוב.
    y1["פרויקט עם סיבה אמיתית ל-WinUI"] --> y2["לא 'המראה חדש'"]
    y2 --> y3["אלא 'חוויית Windows הנוכחית במוצר'"]
    y3 -.-> y4["מוצר חדש ייעודי ל-Windows, הרושם חשוב"]

איור 12: הסיבה האמיתית לבחור ב-WinUI היא לא “חדש” אלא “לשלב את חוויית Windows הנוכחית”.

מצד שני, יש גם נקודות זהירות.

5.3.1 WinUI הוא לא “סתם WPF חדש”

מכיוון שהוא משתמש ב-XAML הוא נראה קרוב, אבל -

• ה-API הבסיסי
• סביבת הפקדים
• מבנה הפרויקט
• הגישה ל-deploy‏/‏packaging
• היחס ל-Windows App SDK

שונים.

כלומר, קצת מסוכן לחשוב עליו כתחליף קליל ל-WPF.

flowchart TB
    accTitle: WinUI אינו סתם WPF חדש
    accDescr: תרשים המראה שהשימוש המשותף ב-XAML גורם ל-WinUI להיראות קרוב ל-WPF, אך ה-API הבסיסי, הפקדים, מבנה הפרויקט, ה-packaging והיחס ל-Windows App SDK שונים, ומסוכן לראות בו תחליף קליל.
    u1["שימוש משותף ב-XAML"] --> u2["אבל הרבה שונה"]
    u2 --> u3["API בסיסי ופקדים"]
    u2 --> u4["מבנה ו-packaging"]
    u2 --> u5["היחס ל-SDK"]
    u5 -.-> u6["מסוכן לראות בו תחליף קליל"]

איור 13: למרות ה-XAML המשותף, WinUI אינו תחליף קליל ל-WPF.

5.3.2 בבחירת WinUI, נושא ההפצה קופץ קדימה

ליישום WinUI 3, packaged הוא ברירת המחדל. מצד שני, Windows App SDK עצמו מטפל גם ב-packaged וגם ב-unpackaged.¹³¹⁴²

כאן חשוב להחליט מוקדם על:

• איך מפיצים
• איך מכניסים את ה-runtime
• האם דרוש package identity
• הפצה פנים-ארגונית, Store,‏ MSIX, או מסלול EXE‏/‏MSI קיים

אבל “להחליט מוקדם” בלבד לא אומר מה בדיוק לבדוק, אז הנה תוכן הבדיקה.

קודם כול, יש שני צירים לקבוע.¹³¹⁵

• packaging: האם לאפליקציה יש package identity
• runtime: להשתמש ב-Windows App SDK כ-framework-dependent, או לצרף אותו כ-self-contained

flowchart TB
    accTitle: שני הצירים שקובעים קודם
    accDescr: תרשים המראה שבתכנון ההפצה של WinUI קובעים קודם שני צירים - ציר ה-packaging, האם לאפליקציה package identity, וציר ה-runtime, האם Windows App SDK כ-framework-dependent או self-contained.
    h1["תכנון ההפצה"] --> h2["ציר ה-packaging"]
    h1 --> h3["ציר ה-runtime"]
    h2 -.-> h4["האם יש package identity"]
    h3 -.-> h5["framework-dependent או self-contained"]

איור 14: בתכנון ההפצה קובעים קודם שני צירים - packaging ו-runtime.

יש שלוש אפשרויות בצד ה-packaging.¹³

אחר כך, קובעים אם דרוש package identity מצד הפיצ’רים. פיצ’רים שרשמית מוגדר עבורם “לא עובד בלי package identity” הם, לדוגמה, אלה:¹³

• ‏background task
• התראות push‏ (WNS)
• ‏share target
• הרחבת תפריט הקשר של Explorer
• שיוך סוגי קבצים וסכימות URI
• ‏startup task
• ‏App Service
• ‏Windows AI API

סדר הבדיקה הבא מעשי בעבודה בפועל.

1. לצאת מהדרישות. האם מתוכננים לשמש פיצ’רים מהרשימה למעלה? אם אפילו אחד, נדרש הצד ה-packaged.
2. לבדוק אם אפשר לוותר על המתקין הקיים. אם לא רוצים לוותר, התשובה היא לא מעבר מלא ל-MSIX אלא packaged שמצביע על מיקום חיצוני. פריסת הבינארי הקיימת ומנגנון העדכון נשארים כמות שהם, ומוסיפים רק את ה-identity.¹³
3. לבדוק בזמן ריצה. ניתן לקבוע אם לתהליך הרץ יש identity באמצעות GetCurrentPackageFullName. אם אין identity, מוחזר APPMODEL_ERROR_NO_PACKAGE. להפך, אם קוראים ל-Windows API ומקבלים E_ILLEGAL_METHOD_CALL או APPMODEL_ERROR_NO_PACKAGE, זה סימן שנתקעים בדרישת package identity.¹³
4. לבדוק בצד המכשיר. אפשר לרשום את החבילות המותקנות באמצעות Get-AppxPackage ב-PowerShell.
5. לבסוף, לקבוע את ה-runtime. אם רוצים להפיץ ב-xcopy או zip - self-contained; אם יוצאים ל-Store - framework-dependent הוא המסלול המוגדר כברירת מחדל.¹⁵

גם ב-WinForms‏/‏WPF ההפצה חשובה, אבל ב-WinUI זה נוטה לקפוץ קדימה. ליישום WinUI 3 חדש packaged הוא ברירת המחדל, ולכן אם לא קובעים כלום, זה עולה אוטומטית על מסלול MSIX.¹³ זה המקום המעט מסובך בעולם הזה - חשבתם שהחלטתם על UI, אבל בפועל החלטתם על אסטרטגיית הפצה.

flowchart TB
    accTitle: הליך בדיקת package identity
    accDescr: תרשים המראה חמישה שלבים - לצאת מהדרישות, לבדוק אם אפשר לוותר על המתקין הקיים, לבדוק בזמן ריצה, לבדוק בצד המכשיר, ולבסוף לקבוע את ה-runtime.
    s1["1. לצאת מהדרישות"] --> s2["2. לבדוק אם אפשר לוותר על המתקין"]
    s2 --> s3["3. לבדוק בזמן ריצה"]
    s3 --> s4["4. לבדוק בצד המכשיר"]
    s4 --> s5["5. לקבוע את ה-runtime"]
    s2 -.-> s6["אם לא רוצים לוותר - packaged למיקום חיצוני"]
    s3 -.-> s7["קביעה לפי GetCurrentPackageFullName"]

איור 15: את הצורך ב-package identity בודקים לפי דרישות, מתקין, זמן ריצה ומכשיר.

5.3.3 “לערבב WinUI בהדרגה לתוך WPF/WinForms קיימים” - קודם מנסים

כאן קל שהציפיות מתנפחות. אבל גם ב-FAQ‏ של Microsoft כתוב שברוח הדברים, אלא אם ה-UI framework מוכן לעבור מעבר מלא, לרוב אי אפשר להשתמש ב-WinUI. גם סביב XAML Islands, בעוד התיעוד הרשמי מציג מסלול הטמעה ליישומי שולחן עבודה קיימים, הערות השחרור של Windows App SDK 1.4 אומרות שנכון לעכשיו הבדיקה מתמקדת בעיקר ביישומי C++, ואין רכיבי wrapper נוחים ל-WPF‏/‏WinForms.¹⁰¹¹

כלומר,

• “נראה שאפשר מעבר הדרגתי”
• “נראה שאפשר למלא בהדרגה”

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

‏WinUI הוא הבחירה ההגיונית ביותר כאשר -

• מתחילים מחדש
• בונים חוויה כמוצר ייעודי ל-Windows

לעומת זאת, כפתרון קליטה למעבר מלא מ-WPF‏/‏WinForms קיימים, דרושים סיבה ובדיקה.

flowchart TB
    accTitle: לבדוק לפני שהופכים לאסטרטגיה ראשית
    accDescr: תרשים המראה שהרעיון לערבב WinUI בהדרגה מושך, אך ה-FAQ מניח מעבר מלא, ואין רכיבי wrapper נוחים ל-WPF ו-WinForms, ולכן בודקים קטן לפני שהופכים את זה לאסטרטגיה הראשית.
    v1["רוצים לערבב WinUI בהדרגה"] --> v2["רעיון מושך"]
    v2 --> v3["ה-FAQ מניח מעבר מלא"]
    v3 --> v4["אין wrapper נוח ל-WPF/WinForms"]
    v4 --> v5["בודקים קטן לפני אסטרטגיה ראשית"]

איור 16: “לערבב WinUI בהדרגה” - בודקים קטן לפני שזה הופך לאסטרטגיה הראשית.

6. טעויות שיקול דעת נפוצות

6.1 “כי הוא הכי חדש - WinUI”

זה מובן, אבל מסוכן למדי.

עדיף לבחון סיבה לבחירת טכנולוגיה חדשה לפי האם יש ערך שאי אפשר להשיג בלי הטכנולוגיה הזו.

• האם חוויית Windows מודרנית היא ערך המוצר
• רוצים לנצל את Fluent בטבעיות
• זה מוצר חדש
• אפשר לקבל את הנחות ההפצה/תפעול

אם התשובה כאן “כן”, WinUI אפשרות טובה. לעומת זאת, אם זה רק “נראה שיש לו עתיד”, ההסבר לעלות חלש.

flowchart TB
    accTitle: לא "כי הוא חדש" אלא לפי ערך
    accDescr: תרשים המראה שסיבה לבחירת טכנולוגיה חדשה צריכה להיבחן לפי ערך שאי אפשר להשיג בלעדיה, ואם התשובה כן WinUI אפשרות טובה, ואם רק "נראה שיש עתיד" ההסבר לעלות חלש.
    q0["סיבה לבחירת טכנולוגיה חדשה"] --> q1{"יש ערך שלא ניתן בלעדיה"}
    q1 -->|"כן"| q2["WinUI אפשרות טובה"]
    q1 -->|"רק 'נראה שיש עתיד'"| q3["ההסבר לעלות חלש"]

איור 17: לא “כי הוא הכי חדש” - בוחרים לפי ערך שאי אפשר להשיג בלי הטכנולוגיה.

6.2 “רוצים Windows App SDK, אז חייבים WinUI”

קל לטעות כאן, אבל זה לא נכון.

את Windows App SDK אפשר להוסיף גם ל-WPF‏/‏WinForms קיימים. גם ב-FAQ הרשמי מוסבר שיישומי WPF‏/‏MFC‏/‏WinForms יכולים להשתמש ב-API‏-ים של Windows App SDK שאינם קשורים ל-WinUI.¹⁰⁸⁹

לדוגמה, פיצ’רים כמו

• ‏App Lifecycle
• ‏Windowing
• ‏Toast Notifications

אפשר לפעמים לשלב תוך שמירה על ה-UI הנוכחי.¹⁰

6.3 “WPF/WinForms כבר גמורים”

גם כאן עדיף שלא לפסול בקלות.

גם WinForms וגם WPF ממשיכים לקבל תיעוד ומסלולי הגירה על גבי ‏.NET‏ הנוכחי, ומטופלים רשמית כ-UI פעיל של שולחן העבודה ב-Windows.³⁴

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

כלומר, מנקודת מבט של תחזוקה ארוכת טווח, אפשר לקרוא את זה כך:

• ‏WPF ו-WinForms אינם “קפואים ונטושים” - הם מקבלים פיצ’רים בכל שחרור שנתי של .NET. עם זאת, לחלק מהפיצ’רים המרכזיים של WinForms יש שלב ניסיוני, אז צריך לבדוק את תזמון האימוץ.
• בבחירת WinUI, מנהלים בנפרד את תאריך התמיכה של .NET ואת תאריך התמיכה של Windows App SDK. בפרויקטים ארוכי טווח, זה משפיע בלי רעש.
• לא משנה מה בוחרים, אין ערובה ל”עובד ללא שינויים גם בעוד 10 שנים”, אז עדיף לקבוע מראש עד איזו גרסה עוקבים.

flowchart TB
    accTitle: איך קוראים תחזוקה ארוכת טווח
    accDescr: תרשים המראה ש-WPF ו-WinForms מקבלים פיצ'רים עם כל שחרור שנתי של .NET, ושבבחירת WinUI מנהלים בנפרד את תאריכי התמיכה של .NET ושל Windows App SDK, ולכן קובעים מראש עד איזו גרסה עוקבים.
    m1["WPF / WinForms"] --> m2["פיצ'רים נכנסים עם שחרור .NET"]
    m3["WinUI"] --> m4["מנהלים בנפרד תאריכי תמיכה SDK"]
    m2 --> m5["קובעים מראש עד איזו גרסה עוקבים"]
    m4 --> m5

איור 18: בתחזוקה ארוכת טווח בודקים מה מוביל את העדכונים, וקובעים מראש עד לאן עוקבים.

במיוחד ביישומים עסקיים, לרוב

• נכסים קיימים
• פקדי צד שלישי
• מספר המסכים
• דוחות והדפסה
• חיבור למכשירים
• הליכי הפצה

שוקלים יותר מחדשנות ה-UI‏ framework.

6.4 “אם כבר, כתיבה מחדש מלאה”

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

אם יש יישום קיים, הדברים שכדאי לבדוק ראשונים הם אלה:

1. מה באמת מטריד
2. האם זו בעיית UI, או בעיית ארכיטקטורה
3. האם ה-DLL/COM/OCX התלויים, הדוחות וההפצה הם באמת הנטל האמיתי
4. האם אפשר לפתור את הבעיה בלי לשנות את כל ה-UI

כתיבה מחדש ל-UI מרשימה, אבל גם העלות שלה מרשימה. ומעל לכך, גם אם המראה מתחדש, המורכבות הסובבת נשארת לרוב כמות שהיא.

flowchart TB
    accTitle: ארבע שאלות לפני כתיבה מחדש מלאה
    accDescr: תרשים המראה שכתיבה מחדש מלאה קרובה להחלטה עסקית, ולכן בודקים קודם מה באמת מטריד, האם זו בעיית UI או ארכיטקטורה, האם התלות וההפצה הם הנטל האמיתי, והאם אפשר לפתור בלי לשנות את כל ה-UI.
    r1["1. מה באמת מטריד"] --> r2["2. UI או ארכיטקטורה"]
    r2 --> r3["3. תלות והפצה - הנטל האמיתי?"]
    r3 --> r4["4. אפשר לפתור בלי לשנות UI?"]
    r4 -.-> r5["גם לכתיבה מחדש עלות מרשימה"]

איור 19: לפני כתיבה מחדש מלאה, בודקים בארבע שאלות מה באמת מטריד.

6.5 “אחר כך אפשר לפתור עם XAML Islands”

אפשר להבין את הציפייה הזו. אבל בטוח יותר לא להתייחס אליה כסירת הצלה מלכתחילה.¹⁰¹¹

לפני מעבר הדרגתי, כדאי לבדוק קטן קודם:

• אילו פקדים רוצים להטמיע
• מה קורה עם focus, קלט, DPI ותמה
• האם תצורת ה-host הזו יציבה בפועל

flowchart TB
    accTitle: בודקים XAML Islands קטן מראש
    accDescr: תרשים המראה שבמעבר הדרגתי בודקים מראש קטן אילו פקדים רוצים להטמיע, מה קורה עם focus, קלט, DPI ותמה, והאם תצורת ה-host יציבה, ולא מתייחסים לזה כסירת הצלה מלכתחילה.
    p0["הציפייה 'אחר כך יסתדר'"] --> p1["אילו פקדים להטמיע"]
    p0 --> p2["focus, קלט, DPI, תמה"]
    p0 --> p3["האם תצורת ה-host יציבה"]
    p1 --> p4["בודקים קטן מראש"]
    p2 --> p4
    p3 --> p4

איור 20: את XAML Islands בודקים קטן מראש, ולא מתייחסים אליו כסירת הצלה.

7. נקודת המבט כשמניחים יישום קיים

כאן, הקיים חשוב יותר מהחדש.

7.1 אם יש WinForms קיים

קודם, לפני שקופצים ישר ל-WinUI, בודקים את אלה:

• אפשר להתקרב ל-.NET הנוכחי
• דרוש מעבר ל-64bit
• אפשר לסדר async/await, טיפול בחריגות, הגדרות ולוגים
• אפשר להעלות תחזוקתיות דרך פיצול מסכים או המרה ל-UserControl
• אפשר להוסיף רק את פיצ’רי Windows הדרושים דרך Windows App SDK

לא נדיר שמה שנראה כבעיית WinForms הוא בפועל רק

• ערבוב בין המסך ללוגיקה
• גבולות thread רשלניים
• אחריות דחוסה של הגדרות/קבצים/COM/DB

במקרה כזה, גם מעבר ל-WinUI רק ישאיר את הבעיה עם שם אחר.

flowchart TB
    accTitle: הבעיה נשארת עם שם אחר
    accDescr: תרשים המראה שמה שנראה כבעיית WinForms הוא לרוב בעיית מבנה - ערבוב מסך ולוגיקה, גבולות thread רשלניים, אחריות דחוסה - ובמקרה כזה גם מעבר ל-WinUI ישאיר את הבעיה עם שם אחר.
    e1["נראה כבעיית WinForms"] --> e2["בפועל בעיית מבנה"]
    e2 --> e3["ערבוב מסך ולוגיקה"]
    e2 --> e4["גבולות thread רשלניים"]
    e2 --> e5["אחריות דחוסה"]
    e4 --> e6["מעבר ל-WinUI - נשאר עם שם אחר"]

איור 21: בעיה שנראית כבעיית UI היא לרוב בעיית מבנה, ונשארת גם אחרי החלפת framework.

7.2 אם יש WPF קיים

קל לנצל את הנכסים הקיימים ב-WPF.

• נכסי XAML
• ‏Binding
• ‏Style‏/‏Template
• ‏Command
• ‏MVVM

הסיבה לזרוק את אלה צריכה להיות ברורה למדי.

לדוגמה, אם -

• רוצים לחדש לגמרי את ה-UI של המוצר
• רוצים ש-Fluent יהיה הציר המרכזי
• מוציאים מודול חדש כמוצר נפרד
• רוצים להתקרב לחוויה חדשה כמוצר ייעודי ל-Windows

זו סיבה לשקול WinUI. אבל רק “כי WPF ישן” - זה חלש.

7.3 מה שבאמת כבד הוא לרוב לא ה-UI

בעבודה בפועל, מה שקשה לרוב מפתיע הוא אלה:

• ‏ActiveX‏/‏OCX
• ‏COM interop
• דוחות עצמאיים
• הדפסה
• שילוב עם Excel‏/‏Office
• ‏DLL נייטיבי
• קונפליקט 32bit‏/‏64bit
• מתקין, הרשאות, עדכון, חתימה

אם מזלזלים כאן, גם ניקוי ה-UI בלבד לא יקל על הפרויקט כולו.

לכן, במעבר יישום קיים, עדיף לא רק להסתכל על ה-UI‏ framework, אלא לעשות מלאי לכל גבול תלות.

flowchart TB
    accTitle: עושים מלאי לכל גבול תלות
    accDescr: תרשים המראה שבעבודה בפועל מה שכבד הוא לרוב ActiveX או COM, דוחות והדפסה, DLL נייטיבי, מתקין ועדכון - לא ה-UI - ולכן עושים קודם מלאי לכל גבול תלות.
    d1["ActiveX / COM interop"] --> d4["מה שכבד באמת - לא ה-UI"]
    d2["דוחות, הדפסה, שילוב Office"] --> d4
    d3["מתקין, הרשאות, עדכון, חתימה"] --> d4
    d4 --> d5["קודם עושים מלאי לכל גבול תלות"]
    d5 -.-> d6["ניקוי ה-UI בלבד לא מקל"]

איור 22: מה שבאמת כבד במעבר הוא לרוב תלות מחוץ ל-UI, ולכן עושים מלאי קודם.

8. חמש השאלות האחרונות למי שמתלבט

אם עדיין מתלבטים, עונים על חמש השאלות האלה בסדר.

8.1 האם הנכסים הקיימים גדולים

• גדולים → משמרים בעיקרון את אותו קו
• קטנים / אין → עוברים לבחירה חדשה

8.2 האם “חוויית Windows מודרנית” הכרחית ליישום הזה

• הכרחית → WinUI אפשרות טובה
• לא כל כך → בודקים אם WPF‏/‏WinForms מספיקים

8.3 האם המסך מבוסס טפסים סטנדרטיים, או דורש כוח ביטוי בסגנון XAML

• מבוסס טפסים סטנדרטיים → WinForms
• ‏style/template/Binding/MVVM חשובים → WPF

8.4 רוצים חידוש מלא של ה-UI, או הוספת פיצ’רי Windows

• חידוש מלא של ה-UI → שוקלים WinUI
• רק הוספת פיצ’רים → בודקים קודם WPF‏/‏WinForms הנוכחיים + Windows App SDK

8.5 האם אפשר להסביר מראש איך מטפלים בהפצה/עדכון/תפעול

• עדיין מעורפל → ב-WinUI ממלאים מוקדם את פרטי ה-packaging/deployment
• רוצים להסתמך חזק על התפעול הקיים → לרוב WPF‏/‏WinForms פחות מחככים

flowchart TB
    accTitle: זרימת חמש השאלות האחרונות
    accDescr: תרשים המראה שעונים בסדר על האם הנכסים גדולים, האם חוויה מודרנית הכרחית, האם המסך מבוסס טפסים או דורש כוח ביטוי, וכך מצמצמים את האפשרויות.
    f1{"האם הנכסים הקיימים גדולים"} -->|"גדולים"| f2["משמרים את אותו קו"]
    f1 -->|"קטנים / אין"| f3{"חוויה מודרנית הכרחית"}
    f3 -->|"הכרחית"| f4["WinUI אפשרות טובה"]
    f3 -->|"לא כל כך"| f5{"מבוסס טפסים סטנדרטיים"}
    f5 -->|"כן"| f6["WinForms"]
    f5 -->|"כוח ביטוי חשוב"| f7["WPF"]
    f2 -.-> f8["אם רק פיצ'רים - קודם SDK"]
    f4 -.-> f9["ממלאים מוקדם packaging והפצה"]

איור 23: עונים בסדר על נכסים קיימים, חוויה ואופי המסך, ומצמצמים את האפשרויות.

חמש השאלות האלה מצמצמות משמעותית. לסיכום גס:

• טופס פנים-ארגוני שבונים מהר → WinForms
• יישום עסקי ל-Windows שגדל לאורך זמן → WPF
• UI מוצרי מודרני חדש ל-Windows → WinUI
• מנצלים את הקיים ומתמדרנים רק בפיצ’רי Windows → ה-framework הנוכחי + Windows App SDK

9. סיכום

הבחירה בין WinForms,‏ WPF ו-WinUI היא לא משחק של לסדר לפי חדשנות ולקחת את הימני ביותר.

ארבעת הדברים שכדאי לבדוק ראשונים:

1. איפה נמצאים הנכסים הקיימים
2. האם המסך מבוסס טפסים, או מבוסס כוח ביטוי
3. האם UI מודרני ואופייני ל-Windows הוא דרישת מוצר
4. איך מנהלים הפצה/עדכון/תפעול

אם רואים את ארבעתם, המדיניות כמעט נקבעת.

flowchart TB
    accTitle: ארבע השאלות המסכמות
    accDescr: תרשים המראה שאם רואים את הנכסים הקיימים, אופי המסך, דרישת UI מודרני, והפצה ותפעול, המדיניות כמעט נקבעת.
    n1["נכסים קיימים"] --> n5["המדיניות כמעט נקבעת"]
    n2["אופי המסך"] --> n5
    n3["דרישת UI מודרני"] --> n5
    n4["הפצה ותפעול"] --> n5

איור 24: אם רואים את ארבע השאלות, מדיניות בחירת ה-framework כמעט נקבעת.

• אם יש WinForms קיים גדול - קודם כול המשך עם WinForms
• אם יש WPF קיים גדול - קודם כול המשך עם WPF
• בפיתוח חדש מבוסס טפסים סטנדרטיים - WinForms
• בפיתוח חדש של יישום עסקי בינוני-גדול ל-Windows - WPF
• בפיתוח חדש שבו חוויית Windows מודרנית היא עצמה הדרישה - WinUI
• אם רוצים רק Windows App SDK - לא עוברים ישר לגמרי ל-WinUI

שלושת הדברים שהכי כדאי להימנע מהם:

• לזרוק כי זה ישן
• לבחור כי זה חדש
• להתחיל מתוך “יסתדר בהמשך”

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

10. מקורות

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

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

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

‏מה ההבדל בין WinUI 3 ל-WPF?

שניהם משתמשים ב-XAML, אבל WinUI הוא לא 'סתם WPF חדש'. ה-API הבסיסי, סביבת הפקדים, מבנה הפרויקט, הגישה לפריסה (deploy)/packaging, והיחס ל-Windows App SDK - כל אלה שונים. WPF הוא framework‏ UI המבוסס על ציור וקטורי בלתי-תלוי ברזולוציה, data binding, style/template ו-command, מיועד ליישומים עסקיים בינוניים עד גדולים. WinUI, כחלק מ-Windows App SDK, הוא framework‏ UI מודרני שמניח Fluent, DPI גבוה וחוויית Windows עדכנית. מסוכן לראות בו תחליף קליל ל-WPF.

‏באיזה משלושת - WinForms,‏ WPF או WinUI - לבחור בפיתוח חדש?

התשובה תלויה באופי המסך ובדרישות המוצר. אם רוצים לבנות מהר כלי פנים-ארגוני קטן עד בינוני שמבוסס על פקדים סטנדרטיים וטפסי קלט, WinForms עדיין די חזק. אם מדובר ביישום עסקי בינוני עד גדול עם מסכים רבים, שרוצים לנצל בו כראוי data binding,‏ style,‏ template ו-MVVM, WPF לרוב הבחירה הבטוחה ביותר. עבור מוצר חדש ייעודי ל-Windows שבו Fluent וחוויית Windows מודרנית קשורים ישירות לערך המוצר, WinUI אפשרות טובה. כשיש נכסים קיימים גדולים, קודם כול בוחנים המשך של אותו קו.

‏האם WPF ו-WinForms כבר מיושנים?

עדיף שלא לפסול אותם בקלות. גם WinForms וגם WPF ממשיכים לקבל תיעוד ומסלולי הגירה על גבי ‏.NET‏ הנוכחי, ומטופלים רשמית כ-UI פעיל של שולחן העבודה ב-Windows. במיוחד ביישומים עסקיים, נכסים קיימים, פקדי צד שלישי, דוחות והדפסה, חיבור למכשירים והליכי הפצה שקולים לרוב יותר מחדשנות ה-framework‏ ה-UI. גם בפיתוח חדש, לא נדיר ש-WinForms או WPF הם הבחירה עם הכי מעט חיכוך.

‏האם צריך לעבור ל-WinUI כדי להשתמש בפיצ'רים העדכניים של Windows?

לא. ‏Windows App SDK ו-WinUI אינם אותו דבר - WinUI הוא חלק ה-UI‏ framework בתוך Windows App SDK. את Windows App SDK עצמו אפשר להוסיף גם ליישומים קיימים של WPF‏/‏WinForms‏/‏Win32, ופיצ'רים כמו App Lifecycle,‏ Windowing ו-Toast Notifications אפשר לעיתים לשלב תוך שמירה על ה-UI הנוכחי. כלומר, יש דרך לשמור על WPF‏/‏WinForms הקיימים ולמדרן רק את הפיצ'רים הדרושים של Windows, ומעבר מלא ב-UI אינו הכרחי.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.