ASP.Net या WPF (C #)? [बन्द है]


31

हमारी टीम इस पर विभाजित है और मैं कुछ तृतीय-पक्ष राय लेना चाहता था।

हम एक एप्लिकेशन का निर्माण कर रहे हैं और यह तय नहीं कर सकते हैं कि हम डब्ल्यूसीएफ सर्वर, या एएसपी.नेट वेब ऐप के साथ jQuery का उपयोग करके .net WPF डेस्कटॉप एप्लिकेशन का उपयोग करना चाहते हैं। मैंने सोचा था कि मैं यहाँ सवाल पूछूँगा, कुछ चश्मे के साथ, और देखिए कि दोनों पक्षों का उपयोग करने के पक्ष / विपक्ष क्या होंगे। मेरा अपना पसंदीदा है और मुझे लगता है कि मैं पक्षपाती हूं।

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

दरख्वास्त विस्तार:

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

विचार करने के लिए आइटम (शायद कुछ मामलों में शुरू में नहीं बल्कि भविष्य के रिलीज में):

  • प्रारंभिक रिलीज़ के बाद अतिरिक्त घटकों के लिए कमरा जोड़ा जा सकता है (इनमें से बहुत सारे हैं ... शायद प्रारंभिक आवेदन की तुलना में यहां काम करते हैं)
  • कीबोर्ड नेविगेशन
  • प्रदर्शन एक जरूरी है
  • प्रारंभिक संस्करण के लिए उत्पादन की गति
  • कम रखरखाव ओवरहेड
  • भविष्य का समर्थन
  • सॉफ्टफोन / स्कैनर एकीकरण

हमारे डेवलपर्स:

  • हमारे पास 1 प्रोग्रामर है जो पिछले कुछ महीनों से WPF सीख रहा है और वह था जिसने सुझाव दिया कि हम इसके लिए WPF का उपयोग करें।
  • हमारे पास एक दूसरा प्रोग्रामर है जो ASP.Net से परिचित है और जो भविष्य में इस परियोजना में मदद कर सकता है, हालांकि वह इस पर ज्यादा काम नहीं करेगा, जब तक कि प्रारंभिक रिलीज के बाद से हमारे वर्तमान सॉफ्टवेयर को बनाए रखने में खर्च नहीं किया जाता है।
  • वहाँ मैं है, जिसने दोनों के साथ काम किया है और दोनों में ही सहज हूं
  • हमारे पास परियोजना प्रबंधन करने वाली एक बाहरी कंपनी है, और वे एक ASP.Net कंपनी हैं।
  • हम 1-2 अन्य लोगों को काम पर रखने की योजना बनाते हैं, हालांकि हमें यह जानना होगा कि हम पहले किस दिशा में जा रहे हैं

वातावरण:

  • सामान्य उपयोगकर्ता टर्मिनल सेवाओं के साथ विंडोज 2003 सर्वर पर हैं। वे एक RDP कनेक्शन पर WYSE पतले-क्लाइंट का उपयोग करके कनेक्ट होते हैं। व्यवस्थापक कर्मचारियों के पास XP या उच्चतर के साथ अपने स्वयं के पीसी हैं। उपयोगकर्ताओं को अपने स्वयं के संकल्प को निर्दिष्ट करने की अनुमति दी जाती है, हालांकि वे IE को वेब ब्राउज़र के रूप में उपयोग करने के लिए सीमित हैं।
  • अन्य स्थान एक MPLS कनेक्शन पर हमारे नेटवर्क से जुड़ते हैं

उसके आधार पर, आप क्या चुनेंगे और क्यों?


मैं सभी वोटों से प्यार करता हूं, लेकिन वास्तव में इस पर कुछ और राय सुनना पसंद करेंगे :)
राहेल

3
आप क्या कर रहे हैं कि शुरू में 100 स्क्रीन की आवश्यकता है ?
स्टीवन ए। लोव

उस अनुमान में बहुत सारी आंशिक स्क्रीन शामिल हैं। उदाहरण के लिए, मुख्य स्क्रीन "टुकड़ों" के एक समूह में टूट गई है जिसे उपयोगकर्ता की जरूरतों के अनुसार जोड़ा / हटाया / स्थानांतरित / पुन: आकार दिया जा सकता है। प्रत्येक के पास डेटा का अपना सेट, स्वयं का संपादन दृश्य और प्रदर्शन किए जा सकने वाले कार्यों का अपना सेट है। मैं इन्हें सिंगल स्क्रीन के बजाय अलग-अलग गिन रहा हूं क्योंकि प्रत्येक बहुत अलग है।
राहेल

.NET MVC 3, JQuery और HTML5 का उपयोग करें
ओलिवर पिक्टन

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

जवाबों:


17

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


+1 यह भी, उन सभी स्क्रीनों के साथ, आप संभवतः अपने ऐप (कोड और GUI दोनों) में जितना संभव हो उतना फिर से उपयोग करना चाहते हैं
जॉन ऑनस्टॉट

+1 मुझे लगता है कि "सॉफ्टफोन / स्कैनर एकीकरण" की आवश्यकता है, मुझे लगता है कि एकमात्र तरीका WPF है। या हो सकता है सिल्वरलाइट का उपयोग संभव हो
Jiew मेंग

15

लुनाटिक फ्रिंज उत्तर: दोनों। सर्विस लेयर को सही से प्राप्त करें, एक मोटी क्लाइंट होना आसान है जो सब कुछ (WPF) और एक त्वरित वेब क्लाइंट को सबसे आम चीजें (ASP.NET) करने के लिए करता है। सड़क के नीचे मोबाइल ग्राहक आदि के लिए दरवाजा खुला छोड़ दिया।


यही हम करने की सोच रहे हैं .... रिपोर्ट या सीमित पहुंच के लिए हल्के वेब संस्करण के साथ सबसे अधिक उपयोग के लिए WPF क्लाइंट एप्लिकेशन।
राहेल

2
इसके लिए +1, जो भी .NET लैंग्वेज आरामदायक हो, उसमें नॉन-प्रेजेंटेशन हिम्मत लिखें - फिर प्रत्येक प्रेजेंटेशन टास्क के लिए सबसे अच्छे टूल का उपयोग करें (यानी: इस एप्लिकेशन के लिए ASP.NET इंटरफ़ेस का उपयोग करें, डेस्कटॉप WPF / Winforms / का उपयोग करें) आदि)।
हेट्रिक

प्रारंभ में उपयोगकर्ताओं को ASP.NET 'काफी अच्छा' मिल सकता है, खासकर यदि इसका अर्थ है कि ऐप के अधिक टुकड़े जल्दी हो रहे हैं।
जेएफओ

8

यदि आपके पास केवल एक प्रोग्रामर है जो WPF सीख रहा है और आप अपनी टीम को WPF में कूदने का विचार कर रहे हैं तो इसके बजाय सिल्वर का उपयोग क्यों नहीं करें? आपको WPF के कई फायदे मिलते हैं लेकिन फिर भी एक वेब ऐप के रूप में अपनी परियोजना को छोड़ने की क्षमता बनाए रखता है। चूंकि आप एक बड़े मॉड्यूलर प्रोजेक्ट को देख रहे हैं, इसलिए यह MVVM को सरल बनाने के लिए WPF या सिल्वरलाइट के साथ PRISM का उपयोग करने के लिए समझ में आएगा ।

मेरी टीम ने हाल ही में asp.net पर सिल्वरलाइट का उपयोग करने का विकल्प बनाया है। यह हमारे लिए एक शानदार विकल्प रहा है। हमारे पास शुरू में केवल एक ही डेवलपर था जो किसी भी चांदी की रोशनी को जानता था। फिर हम सभी ने एक सप्ताह का प्रशिक्षण वर्ग लिया जो ज्यादातर बेकार था, लेकिन कम से कम हमारे पैर गीले हो गए। अंत में हमें अपने यूआई ढांचे के थोक के निर्माण में मदद करने के लिए दो ठेकेदारों को नियुक्त करना पड़ा। हमारी टीम का अधिकांश हिस्सा अभी भी उनके चांदी के कौशल में विश्वास नहीं कर रहा है। खुद, चांदी के ज्ञान के साथ शुरुआती टीम के सदस्य, और दो ठेकेदार एसएल विकास के थोक काम कर रहे हैं। उसके बाद हमारे पास दो समर्पित बैक-एंड सदस्य हैं। मैं कहूंगा कि सिल्वरलाइट में जाने का निर्णय लेने के बाद हमें लगभग 2 महीने लग गए थे कि हमारे पास वास्तव में कुछ ठोस था। तथापि, अब हमारे पास एक अद्भुत उत्पाद है जो एक क्लाइंट साइड एप्लिकेशन की तरह लगता है जो वेब ब्राउज़र के अंदर चल रहा है और स्थानीय रूप से किसी भी मशीन पर स्थापित नहीं है। विकास कुल मिलाकर एक वर्ष से कम समय के लिए हुआ है और हम उम्मीदवार को रिहा करने या पहले जारी करने के लिए तैयार हैं।

विचार करने के लिए कुछ बातें:

  • WPF या सिल्वरलाइट, जो भी आप चुनते हैं, एक उचित राशि होगी जिसे आपके डेवलपर्स को सीखना होगा।

  • जरूरत पड़ने पर सिल्वरलाइट ब्राउजर से बाहर चल सकती है। यदि आप ऐसा करते हैं, तो इसे सेट करना बहुत आसान है, ताकि यदि आप कभी भी एक नया संस्करण रोल करते हैं तो ब्राउज़र SL प्रोग्राम से बाहर स्थापित स्वचालित रूप से खुद को अपडेट करेगा।

  • सिल्वरलाइट में WPF के सभी नियंत्रण शामिल नहीं हैं।

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


हम एक समान स्थिति में हैं और मुझे आपकी कहानी, धन्यवाद सुनना दिलचस्प लगा। मैं सिल्वरलाइट पर विचार करूंगा, हालांकि अब तक मैंने केवल WPF का उपयोग किया है। यदि हम WPF के साथ चलते हैं, तो हमने सिल्वरलाइट में अपना रिपोर्टिंग सेक्शन करने की योजना बनाई है, इसलिए मैंने अंततः इसे सीखने की योजना बनाई थी
राहेल

मैं सिल्वरलाइट में एक ASP.NET एप्लिकेशन को परिवर्तित करने (पढ़ने के लिए पुनर्लेखन) के बीच में हूं - मूल रूप से ASP.NET हम जो चाहते हैं उसे करने के लिए कोई पैमाना नहीं है।
ChrisF

1
बस FYI करें: याद रखें कि Silverlight MS का एक प्रमुख उत्पाद नहीं है, और कुछ मामलों में, लोग कह रहे हैं कि यह असंतोष हो सकता है। मैं मानता हूं कि इस पर विचार करना अच्छा होगा, बस इस जानकारी को अपने संभावित विपक्ष की सूची में जोड़ें।
पैज वॉटसन

1
मैं इस तरह के ऐप के लिए सिल्वरलाइट पर WPF पर दृढ़ता से विचार करूंगा। WPF को XBAP (xaml ब्राउज़र एप्लिकेशन) के रूप में आसानी से तैनात किया जा सकता है, आमतौर पर कोड फ़ाइल में केवल कुछ बदलावों के साथ। WPF में सिल्वरलाइट सब कुछ है और अधिक है, प्लस WPF को बहुत अधिक समर्थन मिलता है। एक नकारात्मक पक्ष यह है कि जबकि सिल्वरलाइट संभावित रूप से अधिक ओएस (यहां तक ​​कि मूनलाइट प्रोजेक्ट के साथ लिनक्स) पर तैनात किया जा सकता है, WPF क्लाइंट पर .Net requres।
मॉर्गन हेरलॉकर

2
मुझे नहीं पता कि सिल्वरलाइट को बंद किया जाएगा या नहीं, लेकिन इससे जुड़ी कुछ चीज़ों में शामिल है, मैसेंजर पर माइक्रोसॉफ्ट शिफ़्ट्स ऑफ़ सिल्वरलाइट से एचटीएमएल 5 । निजी तौर पर, मैं गंभीरता से प्योर वेब एप्स पर विचार करूंगा, यदि संभव हो तो डेस्कटॉप या मालिकाना आधारित प्लग इन पर जहां संभव हो
Jiew Meng

7

यह हिस्सा काफी संबंधित है:

सामान्य उपयोगकर्ता टर्मिनल सेवाओं के साथ विंडोज 2003 सर्वर पर हैं। वे एक RDP कनेक्शन पर WYSE पतले-क्लाइंट का उपयोग करके कनेक्ट होते हैं। व्यवस्थापक कर्मचारियों के पास XP या उच्चतर के साथ अपने स्वयं के पीसी हैं। उपयोगकर्ताओं को अपने स्वयं के संकल्प को निर्दिष्ट करने की अनुमति दी जाती है, हालांकि वे IE को वेब ब्राउज़र के रूप में उपयोग करने के लिए सीमित हैं।

दूरस्थ डेस्कटॉप / पतली क्लाइंट कनेक्शनों पर WPF महान नहीं है। एनिमेशन सुचारू नहीं होंगे और कोई भी जटिल चित्र (यहां तक ​​कि ग्रेडिएंट) UI क्रॉल को धीमा कर देगा। विशिष्ट रेट्रो XP मशीनों के साथ व्यवस्थापक कर्मचारियों को भी जटिल WPF अनुप्रयोगों (रैम और खराब GPUs की थोड़ी मात्रा के कारण) के साथ प्रदर्शन की समस्या होगी।

यदि आप समृद्ध ग्राफिक्स के लिए WPF मार्ग पर जाते हैं, तो अंतिम मिनट के प्रदर्शन हैक के लिए तैयार रहें जब आपको पता चले कि लक्ष्य मशीनें दस साल पुरानी हैं। स्थिर स्क्रीन से चिपके रहें और .NET 4.0 का उपयोग करें क्योंकि 3.5 से WPF के प्रदर्शन में नाटकीय रूप से सुधार हुआ है।


धन्यवाद ... यह वास्तव में मेरे लिए एक बड़ी चिंता का विषय है, हालांकि अब तक ऐसा लग रहा है कि हम ग्राफिक्स को स्केल कर सकते हैं यदि उपयोगकर्ता आरडीपी कनेक्शन पर है और परीक्षण ठीक चला है।
राहेल

2

तकनीकी रूप से, मेरा मानना ​​है कि WPF / WCF संयोजन बेहतर समाधान है।

हालाँकि, मुझे विश्वास नहीं है कि आपके मौजूदा WPF प्रोग्रामर के पास वास्तव में इस परियोजना के लिए अनुभव है। WPF प्रोग्रामिंग की प्रक्रियाओं में Winform प्रोग्रामिंग से काफी बदलाव है और इसलिए आपको इस मार्ग को प्रदान करने के लिए टीम में वास्तव में पर्याप्त कौशल होने के बारे में लंबे और कठिन सोचने की आवश्यकता होगी।


1
+1 'कुछ महीनों के लिए सीखना' का अर्थ कुछ भी हो सकता है - एक मजबूत सीखने की अवस्था के लिए तैयार रहना।
कर्क ब्रॉडहर्स्ट

1

दिलचस्प। यह स्पष्ट रूप से एक ऐप से परिचित है जिसे हमने अभी-अभी अपनी कंपनी (एसआईपी फोन और स्कैनर एकीकरण और सभी) में शुरू किया है।

हमने SOA पर फोकस के साथ सिल्वरलाइट को चुना ताकि जरूरत पड़ने पर WPF ऐप को बाद में बनाया जा सके।

प्रारंभिक रिलीज़ के बाद अतिरिक्त घटकों के लिए कमरा जोड़ा जा सकता है (इनमें से बहुत सारे हैं ... शायद प्रारंभिक आवेदन की तुलना में यहां काम करते हैं)

हम सर्विस लेयर में MEF का उपयोग कर रहे हैं, और एक्सटेंशन पॉइंट्स का निर्माण कर रहे हैं (कुछ स्थानों का वर्णन करने वाले प्लगइन इंटरफेस जहां हम एक्स्टेंसिबिलिटी या अन्य सिस्टम के साथ एकीकरण की योजना बनाते हैं)

कीबोर्ड नेविगेशन

एक समस्या नहीं है।

प्रदर्शन एक जरूरी है

किस तरह का प्रदर्शन? प्रतिशत प्रदर्शन (तड़क-भड़क) या नंबर क्रंचिंग प्रदर्शन? उत्तरार्द्ध एक वेब / सिल्वरलाइट ऐप के साथ एक समस्या हो सकती है। पूर्व के लिए, हमारा ऐप आपके जैसे बहुत सारे रिकॉर्डों से गुजरता है, लेकिन हम उन्हें और पूर्व-प्राप्त रिकॉर्ड्स की भविष्यवाणी करने में सक्षम हैं, जबकि उपयोगकर्ता वर्तमान में काम कर रहे हैं। हमारे एप्लिकेशन के उस भाग के लिए 'लोड' समय शून्य है।

प्रारंभिक संस्करण के लिए उत्पादन की गति

कौशल पर निर्भर करता है। लेकिन वास्तविक रूप से, हर कोई हमेशा जितना जल्दी हो सके बाजार में उतरना चाहता है, इसलिए यह एक गैर-तर्क है।

कम रखरखाव ओवरहेड

उत्पादन की गति की तरह, यह भी एक गैर तर्क है और यह डिजाइन और कोडिंग प्रथाओं के लिए नीचे आने वाला है। यदि आप हार्डवेयर रखरखाव के संदर्भ में बोल रहे हैं, तो आप क्लाउड ऐप के साथ जाना चाह सकते हैं।

भविष्य का समर्थन

मुझे यकीन नहीं है कि इसका क्या मतलब है।

सॉफ्टफोन / स्कैनर एकीकरण

सिल्वरलाइट 4 अब वेबकैम / माइक एक्सेस की अनुमति देता है (हम अंतर-एप्लिकेशन वीडियो कॉन्फ्रेंसिंग के साथ-साथ सिप इंटीग्रेशन भी करने की उम्मीद कर रहे हैं), इसलिए यदि आप फोन सर्वर का उपयोग कर रहे हैं, तो आप स्वयं एक लिख सकते हैं। मैं किसी भी मौजूदा लोगों के बारे में नहीं जानता, लेकिन इससे मदद मिल सकती है।

अन्यथा, आपको कुछ बदसूरत हैकिंग करनी पड़ सकती है (लेख / एस, सॉरी के लिए कोई संदर्भ नहीं है) या आपके पास कोई WPF ऐप नहीं है, जो फ़ाइल सिस्टम के साथ इंटरैक्ट कर सके। SL4 ब्राउज़र से बाहर जा सकता है, लेकिन यह केवल फ़ाइल-सिस्टम के कुछ हिस्सों तक पहुंच सकता है। उनमें से कोई भी संभावना नहीं है कि आप एक घूंट फोन के साथ बातचीत करने की आवश्यकता वाले हिस्से होंगे।

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


1

क्या आपको पूरे दिन का उपयोग करने के लिए लोगों के लिए एक संवेदनशील प्रतिक्रियात्मक अनुप्रयोग की आवश्यकता है? WPF का उपयोग करें; आपको एएसपी / एमवीसी (आईएमएचओ) पर WPF में GUI घटकों का पुन: उपयोग करना आसान होगा

हां, jquery et al महान हैं, चांदी की रोशनी शांत है, लेकिन डेस्कटॉप एप्लिकेशन अभी भी अधिक कुशल हैं

बैक-एंड के लिए, WCF ठीक है


0

स्केलेबिलिटी और सिक्योरिटी की वजह से मुझे आपको अपनी सर्विस लेयर के लिए WCF का इस्तेमाल करने की सलाह देनी होगी। प्रस्तुति परत के लिए आप या तो सिल्वरलाइट या ASP.NET का उपयोग कर सकते हैं, सिल्वरलाइट फ्लैश की तरह है, लेकिन यह समझना मुश्किल है और पहले एक उच्च सीखने की अवस्था है, ज्यादातर जब डेटा के साथ काम करना होता है। ASP.NET का उपयोग करना आसान है, लेकिन आपको इसे कुशलतापूर्वक उपयोग करने के लिए बहुत सारे ट्विकिंग और जावास्क्रिप्ट की आवश्यकता होगी।


1
योजना यह है कि हम UI लेयर के लिए क्या करें, इस पर ध्यान दिए बिना WCF सर्विस लेयर रखें। हम यह तय करने की कोशिश कर रहे हैं कि क्या हम क्लाइंट एप्लिकेशन के लिए WPF / Desktop या ASP / Web चाहते हैं। यहां तक ​​कि अगर हम एक डेस्कटॉप ऐप के साथ जाते हैं, तो एक उच्च संभावना है कि हमारे पास रिपोर्ट जैसे मदों के सबसेट तक पहुंचने के लिए एक वेब पोर्टल होगा।
राहेल
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.