أيّها نختار من بين Windows Forms وWPF وWinUI - جدول قرار للتطوير الجديد، الأصول القائمة، التوزيع، والتعبير عن الـ UI

حين نُنشئ تطبيق Windows desktop بـ C# / .NET، ما يبقى دائماً مُعقّداً بصورة هادئة هو اختيار أيٍّ من WinForms وWPF وWinUI.

ما هو خطر هنا، هو طرق الاختيار الضبابية من قبيل،

• WinUI لأنّه الأحدث
• WinForms لأنّه الأكثر اعتياداً
• WPF لأنّه يبدو وسطاً بطريقة ما

في الميدان، المحاور التي ينبغي النظر إليها أوضح قليلاً.

• هل هو تطوير جديد، أم امتداد لأصول قائمة
• هل الشاشة محورها استمارات الإدخال، أم مطلوبٌ منها التعبير
• هل الـ UI الحديث الذي يبدو Windows-style هو قيمة المنتج نفسها
• كيف نُدير التوزيع والتحديث والتشغيل داخل المؤسّسة
• هل الفريق ذو ثقافة Designer، أم ثقافة XAML / MVVM

في هذا المقال، نُنظّم هذه المنطقة في صورة جدول قرار سهل الرؤية على ورقة واحدة. وللتنبيه، WinUI المقصود في هذا المقال يُشير أساساً إلى WinUI 3 + Windows App SDK.¹²

كما أنّ هذه الثلاثة كلّها مخصّصة لـ Windows فقط. إن دخل macOS / Linux في نطاق الرؤية، فإنّ صياغة المسألة أصلاً تختلف.³⁴¹

1. أوّلاً الخلاصة (في كلمة)

إن قلناها بصورة خشنة جدّاً، لكنّها مفيدة في الميدان، فالأمر هكذا.

• إذا كان تطبيق WinForms القائم كبيراً، فننظر أوّلاً إلى مواصلة WinForms كأساس
• إذا كان تطبيق WPF القائم كبيراً، فننظر أوّلاً إلى مواصلة WPF كأساس
• في أداة داخليّة جديدة صغيرة إلى متوسّطة الحجم، إذا كان المحور هو الـ controls القياسيّة وشاشات الإدخال ونريد البناء بسرعة، فإنّ WinForms لا يزال قويّاً جدّاً³⁵
• في تطبيق أعمال جديد متوسّط إلى كبير الحجم بعدد شاشات كبير، إذا أردنا استخدام data binding وstyle وtemplate وcommand وMVVM بصورة جادّة، فإنّ WPF هو الأكثر أماناً غالباً⁴⁶⁷
• في منتج جديد مخصّص لـ Windows، إذا كان الـ Windows UI الحديث وFluent وتجربة Windows الأحدث ترتبط مباشرةً بقيمة المنتج، فإنّ WinUI قويّ¹²
• إن أردنا استخدام أحدث Windows APIs فقط، فإنّ WinUI ليس ضروريّاً. يمكن لـ WPF / WinForms أيضاً تضمين وظائف Windows App SDK²⁸⁹¹⁰
• الاختيار على فرض «يكفي أن أُدخل WinUI تدريجيّاً لاحقاً» خطر قليلاً. حديث الترحيل المرحليّ موحلٌ أكثر ممّا يُتوقّع¹⁰¹¹

باختصار، الأمر تقريباً كما يلي.

1. إذا كانت الأصول القائمة كبيرة، فأبقِ على ذلك النَّسَب أوّلاً
2. في الجديد، إذا أردنا بناء استمارات قياسيّة بسرعة فـ WinForms
3. في الجديد، إذا أردنا تطبيق أعمال Windows ينمو طويلاً فـ WPF
4. في الجديد، إذا كان الـ Windows UI الحديث نفسه هو المتطلّب فـ WinUI
5. إذا كنّا نريد فقط استخدام Windows App SDK، فلا تجعل كلّ شيء WinUI دفعةً واحدة

اختيار الـ framework هو في الوقت ذاته اختيار لتقنية UI و اختيار لتكاليف التوزيع والتشغيل والتعلّم والترحيل. إذا حُسم هذا بمعيار «جديد / قديم» فقط، فإنّ الأثر سيظهر هادئاً لاحقاً. بصورة مزعجة.

2. التقنيّات الثلاث المقصودة في هذا المقال

أوّلاً نُوحِّد المصطلحات قليلاً.

في Microsoft Learn يُوصف WinForms بأنّه إطار يتضمّن controls وgraphics وdata binding ودخل المستخدم، ويسهل بناء التطبيقات عبر drag-and-drop Designer داخل Visual Studio.³

أمّا WPF فهو إطار UI ذو تعبير عالٍ يشمل رسماً قائماً على المتّجهات مستقلاً عن الدقة، وXAML، وdata binding، وstyle / template، و2D / 3D، والرسوم المتحرّكة.⁴

وWinUI جزء من Windows App SDK، وهو إطار UI لـ Windows الحاليّ، يفترض high DPI، دخلاً حديثاً، رسوماً متحرّكة سلسة، وتجربة من نوع Fluent.¹² كما يمتلك بصورة طبيعيّة مسارات لـ data binding / MVVM.¹²

ما يهمّ هنا هو أنّ Windows App SDK وWinUI ليسا الشيء نفسه. WinUI هو الجزء UI من Windows App SDK، أمّا Windows App SDK نفسه فيمكن إضافته أيضاً إلى تطبيقات WPF / WinForms / Win32 القائمة.²¹⁰

ولذلك،

• استخدام WinUI
• استخدام وظائف Windows App SDK

قراران يبدوان متقاربَين لكنّهما مختلفان. حين يختلطان، يصبح الحديث في غرفة الاجتماعات ضبابيّاً قليلاً.

3. جدول القرار على ورقة واحدة

أوّلاً نضع الجدول الأكثر فائدةً في الميدان.

هذا الجدول وحده كافٍ كثيراً، لكنّ النقطتَين اللتَين تُشكّلان حيرةً عادةً هما التاليتان.

1. في تطبيق أعمال Windows جديد، نميل إلى WinForms أم WPF
2. مع وجود WPF / WinForms قائم، هل نذهب إلى WinUI

هاتان النقطتان تُسهِّل التنظيمَ عند النظر إلى جدول المقارنة التالي.

4. جدول المقارنة بحسب الزاوية

هنا ليست جدول أفضليّة رسميّاً، بل مقارنة عمليّة جدّاً.

سرّ القراءة ليس ما هو الأقوى، بل ما الأقلّ احتكاكاً.

مثلاً،

• أداة إعدادات داخليّة
• شاشة إعدادات جهاز
• قائمة، تفاصيل، بحث، إعدادات، أزرار
• استقرار التشغيل وسرعة التعديل أهمّ من المظهر

في هذه الحالات، لا يزال WinForms معقولاً جدّاً.

على العكس،

• عدد الشاشات كبير
• تبديلات حالة العرض كثيرة
• نريد فصل View عن المنطق
• نريد ربط تغيّرات البيانات بالـ UI طبيعيّاً
• نريد ضبط الـ UI عبر style / template

في هذه الحالات، WPF فعّال جدّاً.⁶⁷

ثمّ،

• نريد مظهراً يفترض Windows 11
• نريد الاستفادة الجادّة من Fluent
• نريد افتراض high DPI واللمس وWindow APIs الحديثة
• جديد، ومنتج مخصّص لـ Windows، وانطباع الـ UI مهمّ أيضاً

في هذه الحالات، WinUI طبيعيّ.¹²

5. أيّ مشروع يلائم كلاًّ منها

5.1 WinForms

WinForms يُنظر إليه أحياناً باستهانة، لكن في النقطة الواحدة المتمثّلة في بناء شاشات أعمال محورها controls قياسيّة بسرعة، لا يزال قويّاً جدّاً حتى اليوم.³⁵

من بين ما يلائم بصورة خاصّة، مثلاً:

• أدوات إعدادات داخليّة
• شاشات إعدادات أجهزة وأجهزة قياس وأدوات مراقبة
• شاشات إدارة، شاشات بحث، قائمة + تفاصيل
• مشاريع ذات أصول WinForms قائمة كبيرة
• فِرَق ذات ثقافة قويّة في بناء الشاشات عبر Designer

قوّة WinForms هي أنّه حتى دون استدعاء أفكار صعبة، يمكن إنتاج شاشة قريبة من المنتج النهائيّ بسرعة معقولة. استمارة، زرّ، Label، TextBox، DataGrid. إذا كان هذا العالم هو ساحة المعركة الرئيسيّة، فإنّه يستطيع المنافسة بقوّة.

غير أنّ نقاط ضعفه أيضاً واضحة.

• نريد توحيد مظهر الشاشة كلّه بصورة كبيرة
• نريد التحكّم بالـ UI عبر style وtemplate
• نريد التعامل مع تغيّرات الحالة المعقّدة بمحوريّة data binding
• نريد فصل منطق الشاشة بنظافة

في هذه المنطقة، WPF أو WinUI أكثر طبيعيّةً.

إذا بُني تطبيق كبير بـ WinForms، فمع غفلة بسيطة يصبح غابة من event handlers. لذلك، إذا اخترت WinForms، فمن الأسلم اتّخاذ القرارات التالية منذ البداية على الأقلّ:

• إبقاء مسؤوليّة الشاشة صغيرة
• التقسيم بوحدات UserControl
• الانتباه إلى حدود ما يكافئ Presenter / ViewModel
• عدم لصق منطق الأعمال مباشرةً بأحداث الشاشة

كذلك، ما هو مهمّ جدّاً في الميدان هو أنّه لا حاجة للتخلّي عن WinForms لأنّك تريد استخدام Windows App SDK. رسميّاً أيضاً يوجد مسار لإضافة وظائف Windows App SDK إلى تطبيق WinForms قائم.⁹¹⁰

أيّ أنّ WinForms يُتيح:

• إبقاء الـ UI كما هو
• تحديث الوظائف اللازمة من Windows فقط

كأسلوب اختيار. هذا واقعيّ جدّاً.

5.2 WPF

WPF، بوصفه UI .NET لـ Windows desktop، هو النواة الأكثر توازناً.⁴

نقاط قوّته واضحة جدّاً.

• يمكن كتابة الشاشة بصورة تصريحيّة عبر XAML
• Data Binding قويّ
• يمكن استخدام Style / Template
• يمكن استخدام Command
• يسهل فصل View عن المنطق
• يسهل تنظيم الشاشات متوسّطة إلى كبيرة الحجم

في الوثائق الرسميّة لـ WPF أيضاً، يُوصف data binding بوصفه وظيفةً مركزيّةً، كما تُنظَّم Command بوصفها بنيةً تفصل الإدخال عن منطق التنفيذ.⁶⁷

ولذلك يلائم جدّاً مشاريع من قبيل:

• تطبيق أعمال بعدد شاشات كبير
• قوائم وتفاصيل وتحرير وبحث وعرض حالة كثيرة
• تطبيق Windows يصونه عدد من الأشخاص لمدّة طويلة
• نريد فصل View عن المنطق
• نريد تجهيز فصل مسؤوليّات المظهر والسلوك للتعديلات المستقبليّة
• يبدو أنّ الشاشة ستثقل بسرعة لو استُخدم WinForms

عند الحيرة في تطبيق أعمال جديد مخصّص لـ Windows، WPF لا يزال حتى اليوم خياراً أوّل آمناً جدّاً. قطعه بـ «WPF قديم لا» قاسٍ قليلاً.

بل إنّه إذا تحقّقت الشروط:

• توجد أصول WPF قائمة
• توجد خبرة في XAML / MVVM القائم
• ليست Fluent أولويّةً قصوى إلى هذه الدرجة
• لكنّنا نريد تصميم UI أنظف من WinForms

فإنّ WPF غالباً ما يكون الأفضل مساراً بصورة عاديّة.

طبعاً، لـ WPF أيضاً عاداته.

• إذا أُفرط في XAML تصبح القراءة صعبة
• الدخول في جحيم الـ controls المخصّصة أو templates ثقيل الصيانة
• الميل إلى ديانة «نُنفّذ كلّ شيء بـ Binding» يجعل التتبّع أصعب على العكس

هذه الأمور موجودة. لكنّها ليست لأنّ WPF سيّئ، بل لأنّ الأدوات ذات التعبير القويّ ترتدّ بقوّة إذا لُوِّحَ بها بإهمال.

في WPF أيضاً يمكن إضافة بعض وظائف Windows App SDK. أيّ أنّ هناك مساراً لـ تحديث وظائف Windows مع البقاء على WPF.⁸¹⁰

ولذلك،

• التخلّي الكلّيّ عن WPF والترحيل الشامل إلى WinUI

أقلّ ربحاً في الميدان عادةً من:

• إمالة WPF نحو .NET الحاليّ
• إضافة وظائف Windows اللازمة فقط عبر Windows App SDK
• البدء بتنظيم البنية انطلاقاً من الوظائف الكبيرة الجديدة

هذا الأخير يفوز كثيراً في الواقع.

5.3 WinUI

WinUI هو الخيار الحديث الرئيسيّ عند بناء تطبيق جديد مخصّص لـ Windows.¹²

رسميّاً موقعه:

• مُحسَّن لأحدث الأجهزة وأحدث وسائل الإدخال
• high DPI
• رسوم متحرّكة سلسة
• جزء من Windows App SDK

كما هو موضوع.¹

لذلك يلائم مشاريع من هذا النوع:

• منتج جديد مخصّص لـ Windows
• انطباع الـ UI أو التجربة نفسها مهمّان
• نريد استخدام Fluent بصورة طبيعيّة
• نريد الميل إلى وضع Windows 11 الحاليّ
• نريد افتراض Window APIs جديدة وتجربة Windows أحدث

المشاريع التي لها سبب وجيه لاختيار WinUI، عادةً ما تكون مشاريع «نريد جلب تجربة Windows الحاليّة إلى المنتج» لا مجرّد «المظهر جديد».

من جهة أخرى، هناك نقاط انتباه أيضاً.

5.3.1 WinUI ليس «WPF جديداً فحسب»

لأنّه يستخدم XAML قد يبدو قريباً، لكن

• الـ APIs الأساسيّة
• محيط الـ controls
• بنية المشروع
• طريقة التفكير في deploy / packaging
• طريقة التعامل مع Windows App SDK

كلّها تختلف.

أيّ أنّ اعتباره بديلاً سهلاً لـ WPF خطر قليلاً.

5.3.2 اختيار WinUI يدفع حديث التوزيع إلى الواجهة

تطبيقات WinUI 3 packaged افتراضيّاً. في المقابل، Windows App SDK نفسه يتعامل مع packaged و unpackaged معاً.¹³¹⁴²

ما يهمّ هنا هو أنّه من الأفضل الحسم مبكّراً للأمور:

• كيف نُوزّع
• كيف نُدخل الـ runtime
• هل نحتاج إلى package identity
• هل التوزيع داخليّ، أم Store، أم MSIX، أم مسار EXE / MSI القائم

في WinForms / WPF التوزيع مهمّ أيضاً، لكن في WinUI تظهر هذه الأمور في المقدّمة بسهولة. ظنناً أنّنا نُحدّد الـ UI، فإذا بنا في الواقع نُحدّد استراتيجيّة التوزيع - هذا الجزء المُعقّد قليلاً من هذا العالم.

5.3.3 «خلط WinUI تدريجيّاً مع WPF / WinForms القائم» ينبغي التجريب أوّلاً

هنا منطقة تنتفخ فيها التوقّعات بسرعة. لكن في FAQ من Microsoft أيضاً ما معناه أنّ WinUI كثيراً ما لا يمكن استخدامه ما لم يكن الفريق مستعدّاً لترحيل إطار الـ UI ترحيلاً كاملاً. علاوةً على ذلك، حول XAML Islands، تُقدّم الوثائق الرسميّة مساراً لتضمينه في تطبيقات desktop قائمة، بينما تُشير ملاحظات إصدار Windows App SDK 1.4 إلى أنّ الاستخدام في الوقت الحاليّ مُختبَر أساساً في تطبيقات C++، ولا تتضمّن عناصر wrapper مريحة لـ WPF / WinForms.¹⁰¹¹

أيّ أنّ مقولات:

• «يبدو أنّ الترحيل المرحليّ ممكن»
• «يبدو أنّه يكفي ملؤه تدريجيّاً»

رغم جاذبيّتها كتصوّر، من الأفضل التحقّق منها بحجم صغير قبل اعتمادها استراتيجيّةً رئيسيّةً للمشروع.

WinUI أفضل مساراً حين:

• نبدأ من جديد
• نصنع تجربة منتج مخصّص لـ Windows

على العكس، بوصفه وعاءً للاستبدال الكامل لـ WPF / WinForms القائم، يلزمه سبب وتحقّق.

6. أخطاء قرار شائعة

6.1 «WinUI لأنّه الأحدث»

هذا واضح، لكنّه خطر جدّاً.

سبب اختيار تقنية جديدة، الأسلم النظر إليه من زاوية هل هناك قيمة لا يمكن الحصول عليها إلّا بهذه التقنية.

• هل تجربة Windows الحديثة قيمة منتج
• هل نريد استخدام Fluent بصورة طبيعيّة
• هل المنتج جديد
• هل يمكن قبول مقدّمات التوزيع / التشغيل

إذا كانت الإجابة هنا نعم، فإنّ WinUI قويّ جدّاً. على العكس، مجرّد «يبدو أنّ له مستقبلاً» تفسير ضعيف للتكلفة.

6.2 «لاستخدام Windows App SDK يجب الذهاب إلى WinUI»

يُساء فهم هذا بسهولة، لكنّه مختلف.

يمكن إضافة Windows App SDK إلى WPF / WinForms القائم أيضاً. في FAQ الرسميّ أيضاً مُنظَّم أنّ تطبيقات WPF / MFC / WinForms يمكنها استخدام Windows App SDK APIs غير المرتبطة بـ WinUI.¹⁰⁸⁹

مثلاً، وظائف من قبيل:

• App Lifecycle
• Windowing
• Toast Notifications

يمكن في كثير من الأحيان تضمينها مع الإبقاء على الـ UI الحاليّ.¹⁰

6.3 «WPF / WinForms انتهى زمنه»

هنا أيضاً، الأفضل عدم القطع بإهمال.

WinForms وWPF كلاهما تستمرّ وثائقهما ومسارات ترحيلهما على .NET الحاليّ، ويُعامَلان رسميّاً بوصفهما UIs لـ Windows desktop عاملة في الخدمة.³⁴

في تطبيقات الأعمال خاصّةً،

• الأصول القائمة
• controls من طرف ثالث
• عدد الشاشات
• التقارير والطباعة
• التكامل مع الأجهزة
• إجراءات التوزيع

كلّ هذه غالباً ما تكون أثقل من حداثة إطار الـ UI، وذلك بصورة عاديّة.

6.4 «ما دمنا نُعيد فلنُعد كتابة كلّ شيء»

إعادة الكتابة الكاملة أقرب إلى قرار أعمال منها إلى اختيار تقنيّ.

إذا كان هناك تطبيق قائم، فأوّل ما ينبغي النظر إليه هو التالي:

1. ما الذي يُسبّب الإزعاج فعلاً
2. هل المشكلة في الـ UI، أم في البنية
3. ألَيست تبعيّات الـ DLL / COM / OCX / التقارير / التوزيع هي الأعباء الفعليّة
4. هل تُحلّ المشاكل دون تغيير الـ UI كلّه

إعادة كتابة الـ UI لافتة، لكنّ تكلفتها لافتة أيضاً. وفوق ذلك، حتى لو تجدّد المظهر، فإنّ التعقيدات المحيطة عادةً ما تبقى.

6.5 «سيُنقَذ الأمر لاحقاً عبر XAML Islands»

هذا التوقّع مفهوم. لكن، الأسلم عدم معاملة هذا قارب نجاة منذ البداية.¹⁰¹¹

في الترحيل المرحليّ، الأفضل التجريب الصغير مسبقاً للأمور التالية:

• ما الـ controls التي نريد تضمينها
• كيف ستكون حالة focus والإدخال وDPI والـ theme
• هل سيستقرّ ذلك التشكيل المُستضِيف فعلاً

7. نظرة حين يكون التطبيق القائم هو المقدّمة

هنا، الأهمّ هو القائم لا الجديد.

7.1 إذا كان WinForms قائماً

أوّلاً، قبل القفز إلى WinUI مباشرةً، انظر إلى التالي:

• هل يمكن الميل إلى .NET الحاليّ
• هل التحويل إلى 64bit ضروريّ
• هل يمكن تنظيم async / await، معالجة الاستثناءات، الإعدادات، السجلّات
• هل يمكن رفع قابليّة الصيانة عبر تقسيم الشاشات أو UserControl
• هل يمكن إضافة وظائف Windows اللازمة فقط عبر Windows App SDK

ما يبدو مشكلةً في WinForms كثيراً ما يكون في الواقع مجرّد:

• اختلاط الشاشة بالمنطق
• حدود الـ thread فوضويّة
• اكتظاظ مسؤوليّات الإعدادات / الملفّات / COM / DB

في تلك الحال، الانتقال إلى WinUI سيُبقي المشكلة باسم آخر فقط.

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
• الـ installer والصلاحيّات والتحديث والتوقيع

الاستهانة بهذا تجعل تنظيف الـ UI وحده غير قادر على تخفيف المشروع كلّه.

ولذلك، في ترحيل التطبيقات القائمة، الأَولى ليس فقط النظر إلى إطار الـ 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 أقلّ احتكاكاً غالباً

هذه الأسئلة الخمسة تُضيِّق دائرة الاختيار كثيراً. لو لخّصنا في النهاية بصورة خشنة، فالأمر هكذا:

• استمارة داخليّة سريعة البناء → WinForms
• تطبيق أعمال Windows ينمو طويلاً → WPF
• UI منتج Windows حديث جديد → WinUI
• الإبقاء على القائم مع تحديث وظائف Windows فقط → الإطار الحاليّ + Windows App SDK

9. الخلاصة

اختيار WinForms أو WPF أو WinUI ليس لعبة الترتيب من الأحدث وأخذ الأقصى يميناً.

أوّل ما ينبغي النظر إليه هو الأمور الأربعة التالية:

1. أين تقع الأصول القائمة
2. هل الشاشات محورها استمارات أم محورها التعبير
3. هل الـ UI الحديث الذي يبدو Windows-style شرط منتج
4. كيف نُدير التوزيع / التحديث / التشغيل

إذا اتّضحت هذه الأربعة، فالتنظيم تقريباً كما يلي:

• إذا كنّا نمتلك WinForms قائماً بحجم كبير، فأوّلاً مواصلة WinForms
• إذا كنّا نمتلك WPF قائماً بحجم كبير، فأوّلاً مواصلة WPF
• في الجديد إذا كان المحور استمارات قياسيّة فـ WinForms
• في الجديد إذا كان تطبيق أعمال Windows متوسّط إلى كبير فـ WPF
• في الجديد إذا كانت تجربة Windows الحديثة نفسها هي الشرط فـ WinUI
• إذا كنّا نريد فقط استخدام Windows App SDK فلا نجعل كلّ شيء WinUI دفعةً واحدة

ما نريد تجنّبه أكثر هو الثلاثة:

• التخلّي لأنّه قديم
• الاختيار لأنّه جديد
• البدء بتعويل على «سيُحلّ الأمر في منتصف الطريق»

عالم Windows desktop عالمٌ تكون فيه الأصول والتوزيع والتشغيل وعلاقات التبعيّة أثقل من المظهر. ولذلك، طرق الاختيار أيضاً، الأفضل النظر إلى قلّة الاحتكاك بدلاً من البريق، فهذا غالباً ما يفوز.

10. مراجع

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.