विंडोज 8 के लिए आर्किटेक्चर एंटरप्राइज डेस्कटॉप एप्लिकेशन कैसे करें

Question

मुझे लगता है कि मेरे पास विंडोज 8 के लिए उपभोक्ता अनुप्रयोग विकास की उम्मीदों पर एक पकड़ है। WinRT के ऊपर एक नया मेट्रो-आधारित यूआई बनाएं, इसे मार्केटप्लेस के माध्यम से अपने ग्राहक को वितरित करें, और हर कोई जीतता है। काफी सरल लगता है। दुर्भाग्य से, मैं उस व्यवसाय में नहीं हूं।

मैं एक बड़े उद्यम के लिए आंतरिक, लाइन-ऑफ-बिजनेस एप्लिकेशन पर काम करता हूं। वर्तमान में हम अमीर UI बनाने के लिए WPF और सिल्वरलाइट जैसी .NET तकनीकों का उपयोग करते हैं जो वेब या क्लिकऑन के माध्यम से हमारे उपयोगकर्ताओं को आसानी से तैनात किया जा सकता है। अनुप्रयोग बहुत अधिक सिरदर्द के बिना WinXP और Win7 का समर्थन कर सकते हैं, और हमारे डेवलपर्स को XAML का उपयोग करने के लिए मिलता है जो एक बहुत ही ठोस UI तकनीक है।

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

मुझे अपने XAML- आधारित अनुप्रयोगों का आर्किटेक्चर कैसा होना चाहिए, वर्तमान में WinXP और Win7 में तैनात किया जा रहा है, ताकि वे Win8 पर सपोर्टेबल और एवेलेबल हों?

इस सवाल के प्रयोजनों के लिए मान लें कि ASP.NET के शीर्ष पर HTML5 द्वारा प्रदान की जाने वाली सुविधाएँ उन अनुप्रयोगों के लिए पर्याप्त नहीं हैं, जिन्हें मैं बनाना चाहता हूं। मैं समझता हूं कि मैं कुछ अनुप्रयोगों के लिए HTML5 का उपयोग कर सकता हूं, लेकिन मैं यह पता लगाने की कोशिश कर रहा हूं कि जब मुझे पर्याप्त नहीं होना चाहिए तो मुझे क्या करना चाहिए।

# 1 संपादित करें: यह @Emmad करीम की टिप्पणी के जवाब में है। मैं इस बात से सहमत हूं कि सिल्वरलाइट / डब्ल्यूपीएफ अल्पावधि (2-5 वर्ष) में व्यवहार्य हैं। हालांकि, हमारे द्वारा उत्पादित अनुप्रयोगों में संभावित रूप से बहुत लंबे जीवनकाल (10-20 + वर्ष) होते हैं। किसी दी गई तकनीक के लिए दीर्घावधि में उत्तरजीविता हमारे लिए चिंता का विषय है। इसके अलावा, हमें कुछ चिंता है कि यह उन डेवलपर्स को खोजने के लिए अधिक से अधिक कठिन होगा जो समुदाय द्वारा "मृत्" माने जाने पर सिल्वरलाइट / डब्ल्यूपीएफ विकास में रुचि रखते हैं। मैं सिर्फ अपने विकल्पों को समझना चाहता हूं और अपनी आंखों से निर्णय लेना चाहता हूं।

Comments

एक बैठक के लिए भागना है, लेकिन मैं तुम्हारे लिए एक जवाब मिल गया है :)

— माइकल ब्राउन

आप पहले से परिचित WPF / Silverlight को क्यों बदलेंगे? आपका कथन "WPF और सिल्वरलाइट में संदिग्ध वायदा है", ठीक है, Microsoft इस तकनीक को रात में नहीं गिराएगा। क्या यह बढ़ता रहेगा यदि आप आज इसके साथ पर्याप्त कार्यक्षमता रखते हैं तो यह वास्तविक चिंता नहीं है। संक्षेप में, आपके पास एक पूरी तरह से नई वास्तुकला पर विचार करने के लिए एक ठोस तकनीकी कारण होना चाहिए। वहाँ से बाहर डरे हुए लोगों में से कुछ अभी तक एक और तकनीक के लिए अपने अनुभव को खोने से है। मैं उन्हें दोष नहीं दे सकता।

— NoChance

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

— थॉमस ओवेन्स

आपको क्या लगता है कि आप 20 साल में विंडोज चला रहे होंगे?

— जॉनीबोट्स

@JonnyBoats: क्योंकि हम 20 साल पहले इसे चला रहे थे ? या इसलिए कि उनका मुख्य प्रतिद्वंद्वी एक सिस्टम पर आधारित है और भी पुराना है ? एक विशिष्ट तकनीक के पतन या अस्तित्व की भविष्यवाणी करने का कोई तरीका नहीं है।

— मत्तीव्यू

Answer 1

कैसे मैंने चिंता करना बंद करने और एमएस-स्टैक से प्यार करना सीखा

आप अभी भी विंडोज़ 8 पर वीबी 6 ऐप चला सकते हैं । अच्छे या बुरे के लिए रेट्रो-संगतता हमेशा एमएस पारिस्थितिकी तंत्र में एक प्रवृत्ति रही है। आपको WPF / Silveright जैसी प्रौद्योगिकियों के अस्तित्व के बारे में चिंता नहीं करनी चाहिए, और यहां तक ​​कि उस मामले के लिए winforms भी।

दूसरी ओर, आपको यह स्वीकार करना होगा कि दीर्घकालिक परियोजना के लिए, आपके पास नवीनतम, सबसे प्यारी तकनीक कभी नहीं होगी।

वास्तव में आपको अपने आप से एक तकनीक के चुनाव के बारे में प्रश्न पूछना चाहिए:

• क्या मेरी टीम उस तकनीक के साथ पर्याप्त रूप से सहज है जो उत्पादक हो?
• क्या मेरी टीम उस तकनीक का उपयोग करके खुश है?
• क्या मैं उस तकनीक के लिए लोगों की भर्ती कर सकता हूं?

इस प्रश्न के उत्तर का संयोजन यह है कि आपकी पसंद का नेतृत्व करना चाहिए, न कि मुख्य रूप से विपणन कारणों के लिए रुझान।

कभी बदलती प्रौद्योगिकी के इस विषयगत के बारे में अधिक जानने के लिए, आपको जोएल स्पोल्स्की द्वारा "फायर एंड मोशन" पढ़ना चाहिए :

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

और यह लगभग दस साल पहले लिखा गया था।

आर्किटेक्चर और टेक्नोलॉजीज

आर्किटेक्चर और टेक्नोलॉजीज दो अलग-अलग चीजें और विकल्प हैं:

• आप एमवीसी को विनफॉर्म के साथ कर सकते हैं ।
• आप MVVM को WPF / Silverlight के साथ कर सकते हैं ।
• आप ASP.NET के साथ MVC कर सकते हैं ।
• आप क्या कर सकते हैं जो कुछ भी आप चाहते हैं, MVC और MVVM सहित WinRT साथ जहाँ तक हम जानते हैं ।
• आप F # के साथ कार्यात्मक जा सकते हैं । क्यों नहीं ? ऐसे डोमेन हैं जहां यह समझ में आता है।
• आप उन सभी को मिला सकते हैं, एक अलग प्रणाली के विभिन्न प्रवेश बिंदुओं के लिए, फिर मज़ाक किया जा सकता है क्योंकि यह बहुत जटिल हो जाता है , आदि।

आप इन सभी तकनीकों के साथ सेवाओं, संसाधनों, तीसरे पक्ष के नियंत्रण, ओआरएम आदि का उपयोग कर सकते हैं, और हो सकता है, या शायद नहीं, अगले वाले के साथ।

आप उन सभी तकनीकों के साथ एमवीसी को कई तरह से मोड़ और मोड़ सकते हैं: बंधन या नहीं? देखने के पीछे कोड है या नहीं? नियंत्रक या नहीं? ViewModel हर बार या केवल जब जरूरत हो? एक डिजाइन पैटर्न को लागू करने के कई तरीके हैं, यहां तक ​​कि एक विशिष्ट तकनीक के दायरे में भी।

यह आपकी परियोजना और टीम के उन्नत ज्ञान के बिना आपको उनमें से एक में मजबूर करने के लिए अवास्तविक होगा। यह केवल व्यक्तिगत प्राथमिकताओं पर आधारित होगा, और "मेरी तकनीक आपकी तुलना में बेहतर है" शो-अप में अंत होगा।

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

आपकी वास्तुकला और चुने हुए प्रौद्योगिकी का मुख्य उद्देश्य अपने मालिक / ग्राहक को एक उत्पाद वितरित करना है जो उसकी यथार्थवादी आवश्यकताओं को पूरा करता है।

MVC (और यह छोटा भाई MVVM है) OOP भाषाओं के क्षेत्र में और उसके बाद 1979 से मजबूत वास्तुकला का एक आधार साबित हुआ । लेकिन 10 साल की लंबी परियोजना में किस विशिष्ट तकनीक का उपयोग किया जाना चाहिए, यह चुनना आपका निर्णय होना चाहिए।

Comments

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

— रेशनलगीक

@jkohlhepp: वास्तुकला और प्रौद्योगिकियों के बारे में एक पैराग्राफ जोड़ा गया। मैं अपनी बात कहता हूं कि एक तकनीक को दूसरे पर या दूसरे पर एक आर्किटेक्चर के लिए उद्देश्यपूर्ण रूप से सलाह देना असंभव है।

— मत्तीव्यू

आपका रुख यह है कि आर्किटेक्चर / प्रौद्योगिकियों की तुलना करने का कोई उद्देश्य आधार नहीं है? आर्किटेक्चर का पूरा उद्देश्य अनुशासन नहीं है? मैं सहमत हूं कि यह मेरे मालिकों की आवश्यकताओं के बारे में है। उन आवश्यकताओं में से एक सस्ती लागत के लिए अधिकतम दीर्घायु है, इसलिए यह सवाल है।

— रेशनलगीक

@jkohlhepp: IMHO सॉफ्टवेयर आर्किटेक्चर अनुशासन दवा की तरह है। आपको किसी विशिष्ट बीमारी का सही इलाज खोजने का अनुभव मिलता है। कुछ समय में ऐसा करने के विभिन्न तरीके हैं, और एक ही उपचार के साथ सभी को ठीक करने की कोशिश करना खतरनाक हो सकता है। यदि आपके पास WPF और सिल्वरलाइट में अनुभवी प्रोग्रामरों की एक प्रभावी टीम है, तो इसके साथ रहें, और अपनी मौजूदा वास्तुकला को बनाए रखें। यदि आपको इसे बदलना है, तो इसे केवल इसलिए न बदलें क्योंकि कुछ करने के नए तरीके हैं, जो आपके पहले से ही कुशलता से कर रहे हैं, Microsoft द्वारा विपणन किया गया है।

— Matthieu

मैं उस मैथ्यू के साथ बोर्ड पर उतर सकता हूं। विचारशील प्रतिक्रियाओं के लिए धन्यवाद।

— रेशनलगीक

Answer 2

MVVM पर अपनी पुस्तक में मैं एक बात बताऊंगा कि कैसे पुन: प्रयोज्य कोर एप्लिकेशन बनाने के लिए पैटर्न का लाभ उठाया जाए। आपको अपने द्वारा लक्षित विभिन्न प्लेटफार्मों के लिए एक देशी यूआई बनाना चाहिए (यह वेब, सिल्वरलाइट, फोन, डब्ल्यूपीएफ, या WinRT हो)। लेकिन अधिकांश भाग के लिए, आप तर्क को उस UI को एक ViewModel के पीछे चला सकते हैं।

आपके द्वारा एक्सेस की जाने वाली किसी भी सेवा को एक इंटरफ़ेस (मुखौटा पैटर्न) के पीछे लपेटा जाना चाहिए जो प्लेटफार्मों के बीच कम या ज्यादा पोर्टेबल है। इंटरफ़ेस को आपके क्लाइंट एपीआई के सामने की तरफ मैप करना चाहिए और पीठ पर लिपटी सेवा के एपीआई का अनुवाद करना चाहिए।

यह रणनीति आपको एक ठोस कोर ढांचा बनाने में मदद करती है जिसके लिए केवल एक नए UI की आवश्यकता होती है जिसके शीर्ष पर स्तरित होना चाहिए। इसे अपने विचार मॉडल की मांसपेशियों के रूप में सोचें, आपकी सेवाएं कंकाल (और अंग) बनाती हैं। WPF / सिल्वरलाइट / WinRT त्वचा का निर्माण करता है।

वास्तव में, एक बात जो मैं अपनी किताब में बहुत पहले इंगित करता हूं, वह यह है कि MVVM उतना नया नहीं है जितना लगता है। डॉल्फिन स्मॉलटाक में एक समान पैटर्न था जिसे उन्होंने MMVC (दो एम के एप्लिकेशन मॉडल और डोमेन मॉडल) कहा था। आज हम जिस ViewModel का उपयोग करते हैं, वह MMVC के एप्लिकेशन मॉडल और नियंत्रक का एक संयोजन है। वास्तव में कई डेवलपर्स पा रहे हैं कि कभी-कभी ViewModel को दो घटकों में अलग करना समझ में आता है (नेविगेशन के लिए इस्तेमाल किया जा रहा नियंत्रक और कई वीएम को ऑर्केस्ट्रेट करना ताकि वीएम अन्य घटकों से अनजान रह सकें)।

Comments

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

— रेशनलगीक

अगर मुझे अनुमान लगाना था ... जबकि HTML5 इन दिनों नया रोष है, तो Microsoft XAML का समर्थन जारी रखना चाहता है क्योंकि वे इसे नियंत्रित करते हैं। उन्होंने जावा से अपना सबक सीखा (वे मूल रूप से जावा को प्रीमियर .NET भाषा के रूप में उपयोग करने की योजना बना रहे थे, जब सूर्य उन पर सभी मुकदमे चला गया) HTML समर्थन पहुंच के लिए है। ठोस सिद्धांतों पर अपने ऐप का निर्माण करना (एक समृद्ध पोर्टेबल ऑब्जेक्ट मॉडल द्वारा समर्थित डिक्लरेटिव यूआई) आपको तूफान के मौसम में मदद करनी चाहिए। यहां तक ​​कि जावास्क्रिप्ट में एमवीवीएम (चेक आउट पीएस) करने के उदाहरण भी हैं।

— माइकल ब्राउन

Answer 3

आप कहते हैं कि XAML ठोस है, लेकिन फिर कहें कि WPF का एक संदिग्ध भविष्य है। जब तक मैं कुछ याद नहीं कर रहा, तब तक WPF XAML का उपयोग करता है और मुझे नहीं लगता कि दोनों कभी अलग हो रहे हैं। क्या कुछ ऐसी खबरें हैं जो मैं WPF के बारे में याद कर रहा हूँ, संभवतः कुछ अन्य आधार प्रौद्योगिकी का उपयोग कर रहा है, या Microsoft के बारे में भी संभवतः एक और नया तरीका सोच रहा है ताकि UI का निर्माण किया जा सके? उस के बाहर, मुझे शक है कि WPF कहीं भी जा रहा है, लेकिन यह पहली बार नहीं होगा जब MS ने हमारे कोड के नावों को रोका हो ...

यदि आपको एक समृद्ध UI ऐप की आवश्यकता है और HTML5 इसमें कटौती नहीं करेगा, और आप ओआरजी विंडोज़ ओएस के लिए प्रतिबद्ध हैं, तो मुझे लगता है कि WPF सबसे अच्छा विकल्प है, क्योंकि यह सबसे अंतिम / सबसे बड़ा अधिकार है, निश्चित रूप से winforms पर ...

Comments

दिशा जो मैंने MS से सुनी है, ने संकेत दिया है कि WPF में दीर्घकालिक भविष्य के लिए बहुत कुछ नहीं है। लेकिन उन्होंने कुछ भी घोषित नहीं किया है। मुझे उम्मीद है कि वे इसे "रखरखाव मोड" में डाल देंगे, जैसे कि उन्होंने LINQ To SQL के साथ किया।

— रेशनलगीक

WPF को विंडोज 8 में हटा दिया गया है (इसमें आपको "डेस्कटॉप मोड" और इमर्सिव मेट्रो अनुभव से बाहर अचानक डंप किया जाता है)। हालाँकि, आप XAML के साथ मेट्रो एप्लिकेशन बना सकते हैं। वे पूरी तरह से अलग तकनीक हैं।

— डोमिनिक

एर्म, इसका कोई भी नहीं है कि डेस्कटॉप अभी भी अनुभव का एक महत्वपूर्ण हिस्सा नहीं है। "पूरी तरह से अलग प्रौद्योगिकियों" के रूप में - वास्तव में? निश्चित रूप से एक विषय पर विविधताओं के बहुत करीब के रूप में WPF बनाम सिल्वरलाइट के साथ पहले से ही मामला है (वर्कफ़्लो के लिए XAML का उपयोग करने के लिए विरोध, के रूप में ...)

— मर्फ़

Answer 4

इस पर मेरा कहना है कि आपको अपने अनुप्रयोगों के कार्यान्वयन विवरण पर बहुत अधिक ध्यान केंद्रित नहीं करना चाहिए। यदि आप एक बड़ी तस्वीर देखते हैं, तो आप अपनी प्रौद्योगिकी निर्भरता को अलग कर सकते हैं। जैसे xaml / wpf / सिल्वरलाइट पर निर्भरता को अलग करके आप यह सुनिश्चित करते हैं कि आप ui घटक / प्रौद्योगिकी को अगली पीढ़ी की तकनीक से बदल सकते हैं और इसलिए 20 साल के समय में भी निरंतरता की गारंटी देते हैं। यह आपके सिस्टम के घटकों को डिकूप करने में भी मदद करेगा और इस तरह के प्रतिस्थापन को करने के प्रभाव का सामना करेगा। (इसमें मैं एक धारणा बनाता हूं कि निरंतरता प्रदान करने के लिए यह एक समाधान के साथ टिंकर करने के लिए ठीक है, ताकि इसे अगली पीढ़ी के प्लेटफॉर्म पर लाया जा सके)

इन प्रौद्योगिकी निर्भरताओं से अलगाव प्रदान करने का एक अन्य तरीका वर्चुअलाइजेशन को सक्षम करना है। यदि आप अपने अनुप्रयोगों को इस तरह से तैयार करते हैं कि आप उन्हें एक vm में चला पा रहे हैं, तो आप 20 वर्षों में ऐसा कर पाएंगे!

Comments

एक निश्चित अर्थ से मैं इस परिप्रेक्ष्य को समझ सकता हूं। हालांकि, मैं है कुछ बिंदु पर एक यूआई प्रौद्योगिकी चयन करने की आवश्यकता है, और उस विकल्प के आधार पर यह प्रतिस्थापन / अभी या बाद में अद्यतन करने की आवश्यकता होगी। मैं एक विकल्प बनाना चाहता हूं जिसके परिणामस्वरूप अधिकतम दीर्घायु हो।

— RationalGeek

जीवन चक्र साइट के अनुसार Silverlight5 अक्टूबर तक 2021 का समर्थन किया जाएगा support.microsoft.com/lifecycle/?p1=16278 तो जो कुछ भी योजना के लिए होता है, यह अभी भी एक ठोस विकल्प है।

— कार्लो कुइप