التدقيق المستقبلي لتطبيق واجهة مستخدم كبير - MFC مع حزمة الميزات 2008، أو C# وWinforms؟

Question

قامت شركتي بتطوير منتج طويل الأمد باستخدام MFC في Visual C++ كمعيار فعلي لتطوير واجهة المستخدم.تحتوي قاعدة التعليمات البرمجية الخاصة بنا على الكثير من التعليمات البرمجية القديمة/القديمة والتي يجب أن تظل قيد التشغيل.بعض هذه التعليمات البرمجية أقدم مني (تمت كتابتها في أواخر السبعينيات) ولا يزال بعض أعضاء فريقنا يستخدمون Visual Studio 6.

ومع ذلك، لحسن الحظ، تم التوصل إلى نتيجة داخلية مفادها أن منتجنا يبدو قديمًا إلى حد ما مقارنة بمنتجات منافسينا، وأنه يجب القيام بشيء ما.

أعمل حاليًا على منطقة جديدة من واجهة المستخدم وهي منفصلة تمامًا عن بقية المنتج.ولذلك فقد أتيحت لي الفرصة لتجربة مجموعات التكنولوجيا "الجديدة" كنوع من أرض الاختبار قبل أن تبدأ العملية الطويلة للتنقل عبر بقية واجهة المستخدم.

لقد كنت أستخدم C# مع Windows Forms وإطار عمل .net لفترة من الوقت في وقت فراغي وأستمتع به، ولكنني أشعر بالقلق إلى حد ما بشأن الصداع الناجم عن التشغيل المتداخل.على الرغم من أن هذا الفرع المحدد من واجهة المستخدم لن يتطلب الكثير من التفاعل مع قاعدة بيانات C++ القديمة، إلا أنني أتوقع أن يصبح هذا مشكلة في المستقبل.

البديل هو مجرد الاستمرار في استخدام MFC، ولكن حاول الاستفادة من حزمة الميزات الجديدة المرفقة مع VS2008.أعتقد أن هذا هو الخيار الأسهل، ولكنني أشعر بالقلق بشأن طول العمر وعدم الاستفادة من جودة .net...

إذن، أيهما أختار؟نحن فريق صغير، لذا من المحتمل جدًا أن يتم قبول توصيتي باعتبارها اتجاهًا مستقبليًا لتطويرنا - أريد أن أقوم بها بشكل صحيح.

هل مات MFC؟هل C#/Winforms هو الطريق للمضي قدمًا؟هل هناك أي شيء آخر أفتقده تمامًا؟مساعدة موضع تقدير كبير!

Answer 1

أنا مطور تطبيق يحتوي على الكثير من رموز MFC القديمة، ولدينا نفس مخاوفك.وكان الدافع الرئيسي لاستراتيجيتنا هو القضاء على أكبر قدر ممكن من المخاطر وعدم اليقين، وهو ما يعني تجنب عملية إعادة الكتابة الكبرى.كما نعلم جميعًا، يفشل TBR في معظم الأوقات.لذلك اخترنا نهجًا تدريجيًا يسمح لنا بالحفاظ على الوحدات النمطية التي لن تتغير في الإصدار الحالي، وكتابة ميزات جديدة مُدارة، ونقل الميزات التي تحصل على تحسينات لإدارتها.

يمكنك القيام بذلك بعدة طرق:

1. استضافة محتوى WPF على عروض MFC الخاصة بك (انظر هنا)

2. بالنسبة لتطبيقات MFC MDI، قم بإنشاء إطار عمل WinForms جديد وقم باستضافة طرق عرض MFC MDI الخاصة بك (راجع هنا)

3. عناصر تحكم مستخدم WinForms المضيفة في مربعات حوار وطرق عرض MFC (انظر هنا)

تكمن المشكلة في اعتماد WPF (الخيار 1) في أنه سيتطلب منك إعادة كتابة واجهة المستخدم بأكملها مرة واحدة، وإلا سيبدو الأمر مصابًا بالفصام.

يبدو النهج الثاني قابلاً للتطبيق ولكنه معقد للغاية.

النهج الثالث هو الذي اخترناه وهو يعمل بشكل جيد للغاية.فهو يسمح لك بتحديث مناطق تطبيقك بشكل انتقائي مع الحفاظ على الاتساق العام وعدم لمس الأشياء التي لم يتم كسرها.

تبدو حزمة ميزات Visual C++ 2008 مثيرة للاهتمام، إلا أنني لم ألعب بها.يبدو أنه قد يساعدك في حل مشكلتك المتعلقة بالمظهر القديم.إذا كان "الشريط" مزعجًا جدًا للمستخدمين، فيمكنك الاطلاع على موردي التحكم MFC و/أو WinForms التابعين لجهات خارجية.

توصيتي العامة هي أن التشغيل المتداخل + التغيير التدريجي أفضل بالتأكيد من التغييرات الشاملة.

---

بعد قراءة متابعتك، يمكنني بالتأكيد أن أؤكد أن مكاسب الإنتاجية لإطار العمل تفوق بشكل كبير الاستثمار في تعلمه.لم يستخدم أحد في فريقنا لغة C# في بداية هذا الجهد، والآن نفضلها جميعًا.

Answer 2

اعتمادًا على التطبيق واستعداد عملائك لتثبيت .NET (ليس كلهم ​​كذلك)، سأنتقل بالتأكيد إلى WinForms أو WPF.تم تبسيط عملية التشغيل التفاعلي مع كود C++ إلى حد كبير من خلال إعادة هيكلة التعليمات البرمجية التي لا تتعلق بواجهة المستخدم في مكتبات الفئات باستخدام C++/CLI (كما لاحظت في اختيارك للعلامات).

المشكلة الوحيدة في WPF هي أنه قد يكون من الصعب الحفاظ على الشكل والمظهر الحالي.يمكن إجراء الانتقال إلى WinForms مع الحفاظ على المظهر الحالي لواجهة المستخدم الرسومية الخاصة بك.يستخدم WPF نموذجًا مختلفًا لدرجة أن محاولة الاحتفاظ بالتخطيط الحالي قد تكون غير مجدية ولن تكون بالتأكيد متوافقة مع روح WPF.يبدو أيضًا أن أداء WPF ضعيف على أجهزة ما قبل Vista عند تشغيل أكثر من عملية WPF.

اقتراحي هو معرفة ما يستخدمه عملاؤك.إذا انتقل معظمهم إلى نظام التشغيل Vista وكان فريقك مستعدًا للقيام بالكثير من أعمال واجهة المستخدم الرسومية، أود أن أقول تخطي WinForms والانتقال إلى WPF.بخلاف ذلك، انظر بالتأكيد بجدية إلى WinForms.في كلتا الحالتين، مكتبة الفصل في C++/CLI هي الحل لمخاوفك المتعلقة بالتشغيل المتداخل.

Answer 3

لا تقدم الكثير من التفاصيل حول ما يفعله الكود القديم الخاص بك أو كيفية تنظيمه.إذا كانت لديك معايير أداء معينة، فقد ترغب في الاحتفاظ ببعض قاعدة التعليمات البرمجية الخاصة بك في لغة C++.سيكون من الأسهل عليك التعامل مع الكود القديم الخاص بك إذا تم عرضه بالطريقة الصحيحة - هل يمكنك الاتصال بقاعدة التعليمات البرمجية الموجودة من C# اليوم؟قد يكون من المفيد التفكير في مشروع للحصول على هذا الهيكل بشكل صحيح.

فيما يتعلق بنقطة WPF، يمكنك القول بأن WinForms قد يكون أكثر ملاءمة.يعد الانتقال إلى WinForms خطوة كبيرة لك ولفريقك.ربما قد يشعرون براحة أكبر عند الانتقال إلى WinForms؟إنه موثق بشكل أفضل، ومزيد من الخبرة في السوق، ومفيد إذا كنت لا تزال بحاجة إلى دعم عملاء Windows 2000.

كنت قد تكون مهتمة في توسيع تطبيقات MFC باستخدام .NET Framework

شيء آخر للنظر فيه هو C++/سطر الأوامر, ، لكن ليس لدي خبرة في ذلك.

Answer 4

أشكركم جميعًا على ردودكم، ومن المطمئن أن أرى أن الإجماع بشكل عام يتبع خط تفكيري.أنا محظوظ لأن برنامجنا يعمل أيضًا على أجهزتنا المخصصة (لصناعة البث) - لذا فإن اختيار نظام التشغيل هو خيارنا حقًا ونفرضه على عملائنا.نقوم حاليًا بتشغيل نظام التشغيل XP/2000، ولكنني أرى رغبة في الانتقال إلى نظام التشغيل Vista قريبًا.

ومع ذلك، نحتاج أيضًا إلى الحفاظ على تحكم دقيق جدًا في أداء وحدة معالجة الرسومات، والذي أعتقد أنه يستبعد تلقائيًا WPF وتسريع الأجهزة؟كان ينبغي علي أن أوضح هذه النقطة في رسالتي الأصلية - آسف.ربما يكون من الممكن استخدام وحدتي معالجة رسوميات...ولكن هذا سؤال آخر تماما ...

لا يتمتع الفريق بأي خبرة مهمة في لغة C# وأنا شخصيًا لست خبيرًا، ولكن أعتقد أن الفوائد الإجمالية طويلة المدى للبيئة المُدارة ربما تفوق الوقت الذي ستستغرقه للوصول إلى السرعة.

يبدو أن Winforms وC# يمتلكانها الآن.

Answer 5

إذا كنت تفكر في الانتقال إلى C# وبالتالي .NET، فإنني سأفكر في Windows Presentation Foundation بدلاً من WinForms.يعد WPF مستقبل العملاء الأذكياء في .NET، والمهارات التي تكتسبها ستتمكن من إعادة استخدامها إذا كنت تريد إنشاء تطبيقات Silverlight مستضافة على المتصفح.

Answer 6

وأنا أتفق مع مشاعر WPF.يبدو أن واجهة المستخدم المستندة إلى العلامات/XML أكثر قابلية للنقل من WinForms.

أعتقد أيضًا أنه يتعين عليك التفكير في فريقك، إذا لم يكن هناك الكثير من مهارات C# الحالية، فهذا عامل مهم، ولكن مع المضي قدمًا، يتضاءل سوق مطوري MFC وينمو C#.

ربما سيكون هناك نوع من النهج التدريجي ممكن؟لقد شاركت في إعادة ترميز التطبيقات القديمة إلى C# كثيرًا، ودائمًا ما يستغرق الأمر وقتًا أطول مما تتوقع، خاصة إذا كنت تحتفظ ببعض الأكواد القديمة، أو إذا كان فريقك ليس على دراية بـ C#.