फ्यूचर प्रूफिंग एक बड़ा यूआई एप्लीकेशन - 2008 फ़ीचर पैक, या सी # और विनफॉर्म के साथ एमएफसी?

मेरी कंपनी ने यूआई विकास के लिए डिफैक्टो मानक के रूप में विजुअल सी ++ में एमएफसी का उपयोग करके एक लंबे समय तक उत्पाद विकसित किया है। हमारे कोडबेस में विरासत/पुरातन कोड का ALOT शामिल है जिसे परिचालन रखा जाना चाहिए। इनमें से कुछ कोड मेरे से पुराने हैं (मूल रूप से 70 के उत्तरार्ध में लिखे गए हैं) और हमारी टीम के कुछ सदस्य अभी भी विजुअल स्टूडियो 6 पर हैं।

हालांकि, एक निष्कर्ष आंशिक रूप से पहुंचा है कि हमारा उत्पाद हमारे प्रतिस्पर्धियों की तुलना में कुछ हद तक पुरातन दिख रहा है, और कुछ करने की जरूरत है।

मैं वर्तमान में यूआई के एक नए क्षेत्र पर काम कर रहा हूं जो शेष उत्पाद से काफी अलग है। इसलिए मुझे यूआई के बाकी हिस्सों में आगे बढ़ने की लंबी प्रक्रिया से पहले 'नए' प्रौद्योगिकी ढेर को साबित करने का मौका दिया गया है।

मैं अपने खाली समय में थोड़ी देर के लिए विंडोज फॉर्म और नेट फ्रेमवर्क के साथ सी # का उपयोग कर रहा हूं और इसका आनंद लेता हूं, लेकिन कुछ हद तक इंटरऑप के कारण सिरदर्द के बारे में चिंतित हूं। यूआई की इस विशेष शाखा को विरासत सी ++ कोडबेस के साथ बहुत अधिक इंटरऑप की आवश्यकता नहीं होगी, लेकिन मैं भविष्य में यह एक मुद्दा बन सकता हूं।

विकल्प सिर्फ एमएफसी के साथ जारी रखना है, लेकिन वीएस -2008 के साथ भेजे गए नए फीचर पैक का लाभ उठाने का प्रयास करें। यह मुझे लगता है कि सबसे आसान विकल्प है, लेकिन मुझे दीर्घायु के बारे में चिंता है और अच्छी गुणवत्ता का लाभ नहीं ले रहा है .net ...

तो, मैं कौन सा चुनूं? हम एक छोटी टीम हैं इसलिए मेरी सिफारिश शायद हमारे विकास के लिए भविष्य की दिशा के रूप में स्वीकार की जाएगी - मैं इसे सही प्राप्त करना चाहता हूं।

क्या एमएफसी मर चुका है? सी #/Winforms आगे रास्ता है? क्या कोई और चीज है जो मैं पूरी तरह गायब हूं? बहुत सराहना में मदद करें!

0
ro fr bn
हां, एमएफसी मर चुका है। WinForms मर रहा है। इस बिंदु पर डब्ल्यूपीएफ आगे बढ़ने का तरीका है। एमएफसी से विनफॉर्म तक स्विच करने से लागत में काफी कमी आएगी, लेकिन WinForms से wpf तक चलने से नाटकीय रूप से लागत कम हो जाएगी। WinForms उन लोगों के लिए एक अच्छा विकल्प है जिन्हें अभी भी विंडोज 2000 मशीनों या विंडोज मोबाइल का समर्थन करने की आवश्यकता है। 3 डी गेम और सीएडी के लिए डायरेक्टएक्स अभी भी सबसे अच्छा है। आईएमएचओ, हर किसी को WinForms पूरी तरह से छोड़ना चाहिए और सीधे डब्ल्यूपीएफ में जाना चाहिए।
जोड़ा लेखक Ray Burns, स्रोत

6 उत्तर

आप अपने विरासत कोड के बारे में बहुत कुछ नहीं देते हैं या यह कैसे संरचित किया जाता है। यदि आपके पास कुछ प्रदर्शन मानदंड हैं तो आप अपने कुछ कोडबेस को C ++ में बनाए रखना चाहेंगे। यदि आपके पास सही तरीके से उजागर किया गया है तो क्या आपके पुराने कोड के साथ इंटरऑप करने में आपके पास एक आसान समय होगा - क्या आप आज मौजूदा कोडबेस को सी # से कॉल कर सकते हैं? इस संरचना को सही करने के लिए एक परियोजना के बारे में सोचने लायक हो सकता है।

डब्ल्यूपीएफ के बिंदु पर, आप तर्क दे सकते हैं कि WinForms अधिक उपयुक्त हो सकता है। WinForms पर जाना आपके और आपकी टीम के लिए एक बड़ा कदम है। शायद वे WinForms के कदम के साथ और अधिक आरामदायक हो सकता है? यह बेहतर दस्तावेज है, बाजार में अधिक अनुभव है, और उपयोगी है अगर आपको अभी भी विंडोज 2000 क्लाइंट का समर्थन करने की आवश्यकता है।

You might be interested in Extending MFC Applications with the .NET Framework

विचार करने के लिए कुछ और है सी ++/सीएलआई , लेकिन मैं नहीं करता इसके साथ अनुभव है।

0
जोड़ा

क्या आप सी # और इसलिए .NET पर जाने के लिए देख रहे थे, मैं WinForms की बजाय विंडोज प्रेजेंटेशन फाउंडेशन पर विचार करूंगा। डब्ल्यूपीएफ .NET में स्मार्ट क्लाइंट का भविष्य है, और आपके द्वारा चुने गए कौशल आप पुन: उपयोग करने में सक्षम होंगे यदि आप ब्राउज़र-होस्ट किए गए सिल्वरलाइट अनुप्रयोग बनाना चाहते हैं।

0
जोड़ा

मैं डब्ल्यूपीएफ भावना के साथ सहमत हूं। टैग/एक्सएमएल आधारित यूआई WinForms की तुलना में थोड़ा अधिक पोर्टेबल प्रतीत होता है।

मुझे लगता है कि अगर आपको वर्तमान सी # कौशल नहीं है, तो आपको अपनी टीम पर विचार करना होगा, फिर यह एक कारक है, लेकिन आगे बढ़ना एमएफसी डेवलपर्स के लिए बाजार कम हो रहा है और सी # बढ़ रहा है।

शायद किसी तरह का टुकड़े टुकड़े का दृष्टिकोण संभव होगा? मैं सी # के लिए विरासत अनुप्रयोगों को रिकोड करने में शामिल रहा हूं, और यह अनुमान लगाने के मुकाबले बहुत लंबा समय लगता है, खासकर यदि आप कुछ विरासत कोड रखते हैं, या आपकी टीम सी # के साथ बातचीत नहीं कर रही है।

0
जोड़ा

मैं एक ऐसे ऐप पर डेवलपर हूं जिसमें विरासत एमएफसी कोड का एक टन है, और हमारे पास आपकी सभी चिंताएं हैं। हमारी रणनीति के लिए एक बड़ा चालक उतना जोखिम और अनिश्चितता को खत्म करना था जितना हम कर सकते थे, जिसका अर्थ था बिग रिवाइट से परहेज करना। जैसा कि हम सभी जानते हैं, टीबीआर ज्यादातर समय विफल रहता है। इसलिए हमने एक वृद्धिशील दृष्टिकोण चुना है जो हमें मॉड्यूल को संरक्षित करने की अनुमति देता है जो वर्तमान रिलीज में नहीं बदलेगा, प्रबंधित नई सुविधाओं को लिख रहा है, और उन सुविधाओं को निर्यात कर रहा है जो प्रबंधित करने में वृद्धि कर रहे हैं।

आप इसे कई तरीकों से कर सकते हैं:

  1. अपने एमएफसी विचारों पर होस्ट डब्ल्यूपीएफ सामग्री (देखें यहां )

  2. एमएफसी एमडीआई ऐप्स के लिए, एक नया WinForms फ्रेमवर्क बनाएं और अपने एमएफसी एमडीआई विचारों को होस्ट करें (देखें यहां )

  3. एमएफसी संवाद और दृश्यों में WinForms उपयोगकर्ता नियंत्रण होस्ट करें ( यहां देखें )

WPF (विकल्प 1) को अपनाने में समस्या यह है कि आपको एक बार में अपने सभी UI को फिर से लिखना होगा, अन्यथा यह बहुत स्किज़ोफ्रेनिक दिखाई देगा।

दूसरा दृष्टिकोण व्यवहार्य दिखता है लेकिन बहुत जटिल है।

तीसरा दृष्टिकोण वह है जिसे हमने चुना है और यह बहुत अच्छा काम कर रहा है। यह आपको समग्र स्थिरता बनाए रखने और टूटी हुई चीजों को छूने के दौरान अपने ऐप के क्षेत्रों को चुनिंदा रीफ्रेश करने की अनुमति देता है।

विजुअल सी ++ 2008 फ़ीचर पैक दिलचस्प लग रहा है, हालांकि मैंने इसके साथ नहीं खेला है। ऐसा लगता है कि यह पुरानी दिखने के आपके मुद्दे के साथ मदद कर सकता है। यदि आपके उपयोगकर्ताओं के लिए "रिबन" बहुत झटकेदार होगा तो आप तीसरे पक्ष के एमएफसी और/या विनफॉर्म नियंत्रण विक्रेताओं को देख सकते हैं।

मेरी समग्र सिफारिश यह है कि इंटरऑप + वृद्धिशील परिवर्तन निश्चित रूप से परिवर्तनों को व्यापक करने के लिए बेहतर है।


अपना अनुवर्ती पढ़ने के बाद, मैं निश्चित रूप से पुष्टि कर सकता हूं कि ढांचे के उत्पादकता लाभ इसे सीखने में निवेश से काफी अधिक हैं। हमारी टीम पर किसी ने भी इस प्रयास की शुरुआत में सी # का उपयोग नहीं किया था और अब हम सभी इसे पसंद करते हैं।

0
जोड़ा
उस पर प्रयास/भुगतान निराशाजनक है। उल्लेख नहीं है कि आप कभी नहीं इसे पिक्सेल-बाय-पिक्सेल दाएं दिखेंगे। आप एक "अनैतिक घाटी" प्रभाव के साथ खत्म हो जाएगा।
जोड़ा लेखक Aidan Ryan, स्रोत
पुराने शैली नियंत्रण की तरह दिखने के लिए आप अपने डब्ल्यूपीएफ को थीम कर सकते हैं।
जोड़ा लेखक Andy Dent, स्रोत
WPF शैलियों को पिक्सेल-परिपूर्ण प्राप्त करने में काफी समय लग सकता है लेकिन कुछ घंटों में मैं एक ऐप की शैलियों को इतना सटीक प्राप्त करने में सक्षम था कि कोई भी नहीं - क्यूए लोगों को भी नहीं - एहसास हुआ कि नए वर्ग थोड़ा अलग थे।
जोड़ा लेखक Ray Burns, स्रोत

आपकी प्रतिक्रियाओं के लिए सभी को धन्यवाद, यह देखने के लिए आश्वस्त है कि आमतौर पर सर्वसम्मति मेरी सोच की रेखा का पालन करती है। मैं भाग्यशाली स्थिति में हूं कि हमारा सॉफ्टवेयर हमारे अपने कस्टम हार्डवेयर (प्रसारण उद्योग के लिए) पर भी चलता है - इसलिए ओएस की पसंद वास्तव में हमारा है और हमारे ग्राहकों पर जोर देती है। वर्तमान में हम XP/2000 चला रहे हैं, लेकिन मैं जल्द ही विस्टा में जाने की इच्छा देख सकता हूं।

हालांकि, हमें GPU प्रदर्शन पर बहुत अच्छा नियंत्रण बनाए रखने की भी आवश्यकता है, जो मुझे लगता है कि स्वचालित रूप से wpf और हार्डवेयर त्वरण को नियंत्रित करता है? मुझे अपनी मूल पोस्ट में उस बिंदु को बनाना चाहिए - क्षमा करें। शायद दो जीपीयू का उपयोग करना संभव है ... लेकिन यह एक और सवाल है ...

टीम के पास कोई महत्वपूर्ण सी # अनुभव नहीं है और मैं खुद को कोई विशेषज्ञ नहीं हूं, लेकिन मुझे लगता है कि एक प्रबंधित वातावरण के समग्र दीर्घकालिक लाभ संभवतः उस गति से अधिक हो जाएंगे जो गति तक पहुंचने के लिए होगा।

ऐसा लगता है कि Winforms और C# के लिए अभी यह है।

0
जोड़ा
ऐसा लगता है कि जीपीयू का भी डब्ल्यूपीएफ मेमोरी उपयोग पर बड़ा प्रभाव पड़ता है।
जोड़ा लेखक Aidan Ryan, स्रोत
रे बर्न्स की जानकारी के लिए धन्यवाद। सोच के लिए भोजन।
जोड़ा लेखक Ali Parr, स्रोत
मुझे नहीं पता कि यह आपकी परिस्थिति को प्रभावित करता है या नहीं, लेकिन कम से कम एक ऐसी स्थिति है जिसमें GPF को चलाने पर GPU का उपयोग नहीं किया जाता है: दूरस्थ डेस्कटॉप (आरडीपी/टर्मिनल सेवा)। अधिक सटीक होने के लिए, दूरस्थ मशीन के GPU का उपयोग तब भी नहीं किया जाता जब wpf अनुप्रयोगों को चलाया जा सके। आरडीपी 6.0 के तहत प्राइमेटिव क्लाइंट को प्रतिपादन के लिए वापस भेज दिया जाता है।
जोड़ा लेखक Ray Burns, स्रोत

एप्लिकेशन और आपके ग्राहकों की .NET इंस्टॉल करने की इच्छा के आधार पर (उनमें से सभी नहीं हैं), मैं निश्चित रूप से WinForms या wpf पर जाउंगा। सी ++ कोड के साथ इंटरऑप सी ++/सीएलआई (जैसा कि आपने टैग के चयन में उल्लेख किया है) का उपयोग करते हुए कक्षा पुस्तकालयों में गैर-यूआई कोड को दोबारा सुधारकर बेहद सरल बना दिया है।

डब्ल्यूपीएफ के साथ एकमात्र मुद्दा यह है कि वर्तमान दिखने और महसूस को बनाए रखना मुश्किल हो सकता है। अपने जीयूआई के वर्तमान रूप को बनाए रखते हुए WinForms पर जाकर किया जा सकता है। डब्ल्यूपीएफ इस तरह के एक अलग मॉडल का उपयोग करता है कि वर्तमान लेआउट को रखने का प्रयास करने के लिए शायद व्यर्थ होगा और निश्चित रूप से wpf की भावना में नहीं होगा। डब्ल्यूपीएफ के पास प्री-विस्टा मशीनों पर भी खराब प्रदर्शन होता है जब एक से अधिक डब्ल्यूपीएफ प्रक्रिया चल रही है।

मेरा सुझाव यह पता लगाने के लिए है कि आपके ग्राहक क्या उपयोग कर रहे हैं। यदि अधिकांश विस्टा में चले गए हैं और आपकी टीम बहुत सारे जीयूआई काम करने के लिए तैयार है, तो मैं WinForms को छोड़कर wpf पर जाउंगा। अन्यथा, WinForms पर निश्चित रूप से गंभीरता से देखो। किसी भी मामले में, सी ++/सीएलआई में एक कक्षा पुस्तकालय आपकी इंटरऑप चिंताओं का उत्तर है।

0
जोड़ा
कृपया कई उदाहरणों के साथ खराब wpf प्रदर्शन के लिए संदर्भ प्रदान करें - यह हमारे लिए एक महत्वपूर्ण मुद्दा हो सकता है!
जोड़ा लेखक Andy Dent, स्रोत
मेरी डेवेल मशीनों में से एक एक दोहरी मॉनीटर विंडोज एक्सपी है और मेरे पास अक्सर कई wpf अनुप्रयोग स्क्रीन पर दिखाई देते हैं। मैंने किसी भी प्रदर्शन के मुद्दों पर ध्यान नहीं दिया है। बेशक, मैं विकास के लिए उपयोग किए जाने वाले अनुप्रयोगों में से कोई भी वास्तविक भारी-ड्यूटी ग्राफिक्स अनुप्रयोग नहीं है जिसमें कई चलती वस्तुओं हैं। यदि वह मामला था, तो GPU साझाकरण समस्या ध्यान देने योग्य हो सकती है।
जोड़ा लेखक Ray Burns, स्रोत
विंडोज विस्टा डिस्प्ले ड्राइवर मॉडल ( msdn.microsoft.com/en-us/library/ aa480220.aspx ), एमएसडीएन से
जोड़ा लेखक Zooba, स्रोत