क्लीन .NET के अनन्त सनशाइन

जब मैंने 10 साल पहले .NET फ्रेमवर्क 3.5 (भाषा संस्करण 3.0) के साथ काम करना शुरू किया था, तो मेरे लिए इसकी कार्यक्षमता बेहद सीमित थी, जैसा कि मैंने SharePoint 2010 से शुरू किया था। धीरे-धीरे प्रौद्योगिकियों की एक विस्तृत श्रृंखला का अध्ययन कर रहा हूं और .NET के विकास का अनुसरण कर रहा हूं। मैं जावा के लिए एक संदिग्ध प्रतियोगी से एक शानदार क्रॉस-प्लेटफॉर्म को लिनक्स के लिए डेमॉन विकसित करने की क्षमता के साथ नोट कर सकता हूं (और यह विंडोज के लिए विशेष रूप से इरादा था)। बेशक, जब मैं पहली बार प्रौद्योगिकी में आया था, तो ऐसा लग रहा था कि सब कुछ पर्याप्त था: आखिरकार, लागू करने के तरीके थे जो कि इरादा था। लेकिन अब, विभिन्न प्लेटफार्मों और उनके विभिन्न संस्करणों पर काम करने का अनुभव होने से, हम पहले से ही अनुमान लगा सकते हैं कि जीवन उन दूर के समय में एक दर्द था।

सामान्य तौर पर, अगर यह मानसिक रूप से उस युग में वापस जाता है और "यह था - यह बन गया है" के संदर्भ में .NET पर एक साथ प्रतिबिंबित करता है, तो मैं आपको बिल्ली के लिए आमंत्रित करता हूं। मुझे लगता है कि यह उन दोनों के लिए दिलचस्प होगा जो हाल ही में कोड करते हैं और पिछले संस्करणों की सुविधाओं के बारे में नहीं जानते हैं, और उन लोगों के लिए जो उदासीनता में लिप्त होना चाहते हैं।

दर्द की उम्र

जब मैंने विकसित करना शुरू किया, SharePoint 2010 ने .NET फ्रेमवर्क 3.5 पर काम किया और पहले से ही इसमें बहुत कुछ शामिल था: LINQ दिखाई दिया और आदिम AJAX था। लेकिन यह मंच द्वारा बहुत सीमित था, क्योंकि इसे विस्तारित करना मुश्किल था, और तब बस कोई पर्याप्त उपकरण नहीं थे।

दर्द 1: एक भी आवेदन बनाना

तब "बॉल" के लिए वेब पार्ट्स विकसित करने की तकनीक वेबफार्म पर आधारित थी, जिसमें प्रत्येक वेब पार्ट अनिवार्य रूप से एक अलग एप्लिकेशन होता है। व्यक्तिगत रूप से, मेरे लिए इस तरह का एक भी आवेदन करना अवास्तविक था, क्योंकि वेब पार्ट को विकसित करते समय, उनमें से प्रत्येक डेटाबेस से जुड़ने के लिए अपने स्वयं के संदर्भ को इनिशियलाइज़ करता है - यह पता चलता है कि एकल संदर्भ बनाना असंभव था। उदाहरण के लिए, उदाहरण के लिए, पृष्ठों पर डेटाबेस से डेटा प्रदर्शित करने के लिए, मैंने SqlDataSource का उपयोग किया (अलग से विजेट में डेटाबेस से कनेक्ट करके), और 3-4 तालिकाओं से कनेक्ट करने के लिए, मेरे पास विजेट पर 3-4 डेटा स्रोत थे, जो निश्चित रूप से था , प्रभावित पृष्ठ लोड करने की गति। उस समय तक, ADO.NET एंटिटी फ्रेमवर्क पहले से ही दिखाई दिया था, लेकिन इसे 4.1, संस्करण 4.1 तक SharePoint में उपयोग करने के लिए असुविधाजनक था, क्योंकि उत्पादों की परस्पर क्रिया में समस्याएँ थीं।

दर्द 2: समर्थन और पैटर्न की दुर्गमता

SP 2010 के लिए वेब पार्ट हमने वेब पार्ट SP 2007 बनाने की तकनीक पर लिखा है, क्योंकि 2008 स्टूडियो के लिए कोई टेम्पलेट या समर्थन नहीं थे। धीरे-धीरे, विज़ुअल स्टूडियो 2010 की रिलीज़ के साथ, उनके टेम्प्लेट दिखाई दिए, और काम करना आसान हो गया: वेबसाइट परिभाषा बनाने के लिए और स्टूडियो से उन्हें कोड करना, वांछित सामग्री-प्रकार और सूची विवरण को एनकोड करना संभव हो गया। पहले, यह सब एक्सएमएल फ़ाइलों के संपादन के माध्यम से हाथों से किया गया था, और यह निस्संदेह, उन लोगों के लिए एक दर्द था जो सिर्फ .NET विकास में डूबे हुए थे, क्योंकि व्यक्ति को यह समझ नहीं आया कि वह किस तरह की फाइल को सही कर रहा था और किस उद्देश्य के लिए था, लेकिन केवल इस पर ध्यान केंद्रित किया मंच से चाचा के शब्द।

दर्द 3: अतुल्यकालिक ...

.NET फ्रेमवर्क 3.5 में इस रूप में कोई अतुल्यकालिक there नहीं था जिसे हम अभी जानते हैं, और हमें एक अन्य थ्रेड में कुछ कोड चलाना है, प्रतिनिधि हैंडलर के माध्यम से संचार करना है, और WinForms में एक कार्यकर्ता की पृष्ठभूमि का उपयोग करना संभव था (अर्थात, दूसरी प्रक्रिया। समानांतर में चल रहा है जिसमें काम किया गया था)। यह पता चला है कि अतुल्यकालिक अनुप्रयोगों की प्रोग्रामिंग मौजूद थी, लेकिन उनका कार्यान्वयन जून को समझने से परे था।

.NET फ्रेमवर्क 4 में, टास्क समानांतर लाइब्रेरी दिखाई दी, और इसलिए, कार्य भी दिखाई दिए, अर्थात्। हम प्रतिनिधियों को घोषित नहीं कर सकते हैं, लेकिन एक कार्य करते हैं, उस पर कार्रवाई करते हैं, और इसे एक समानांतर धागे में निष्पादित करते हैं, स्थिति / स्थिति को जानते हुए और जब आवश्यक हो, इसके कार्यान्वयन के बारे में संकेत प्राप्त करते हैं। समानांतर विकास के लिए यह प्रगति थी, जब आपको बड़ी मात्रा में डेटा संसाधित करने की आवश्यकता होती है, क्योंकि इससे पहले यह एक बड़े प्रवेश बार के साथ किया गया था।

... और जमी हुई खिड़कियां

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

दर्द 4: तैनाती आ रही है

.NET फ्रेमवर्क 3.5 में भी एक और दर्दनाक तकनीक थी - एमएस AJAX। UpdatePanel सामग्री बैकएंड से अपडेट की गई थी, जबकि बाकी सब कुछ फिर से नहीं बनाया गया था। SharePoint में, उसने पृष्ठ जीवन चक्र में नियंत्रणों को शुरू करने की बारीकियों के कारण बहुत कुटिलता से काम किया। यहाँ यह हमारे लिए पहली पोस्ट-बैक (कभी-कभी दूसरे के बाद) के बाद काम करता था, और सामान्य तौर पर पहली बार एमएस एजेक्स को अच्छी तरह से काम करना मुश्किल था, हालांकि यह केवल साफ वेबफॉर्म अपडेटपैनलाइन के साथ काफी इस्तेमाल किया गया था। और "बॉल" के उस संस्करण में क्लासिक AJAX (XMLHttpRequest) का उपयोग करना संभव नहीं था, क्योंकि प्रत्येक क्रिया के लिए पीठ पर एक अलग हैंडलर लिखना और उन्हें प्रत्येक वेब पार्ट के एक पैकेट में लटका देना आवश्यक था। उसी समय, इस कार्यक्षमता को हवा देना हमेशा संभव नहीं था।

जब मैंने समानांतर में "पास-बॉल" कार्यों के लिए WebForms पर लिखे गए अन्य अनुप्रयोगों के साथ काम किया, तो मुझे आश्चर्य हुआ कि एसपी के लिए एक परियोजना को तैनात करने की समस्या केवल एसपी के लिए एक समस्या है। बाकी अनुप्रयोगों को इस समय आरम्भ में रखा गया था: खिड़की भरी हुई थी, और यह काम करती है (जादू!)। गुब्बारे में, तैनाती 2 से 3 मिनट से होती है, और आप एक निरंतर चक्र में हैं:



सामान्य तौर पर, हर कोई समझता था कि यह तैनाती और मिनी-ब्रेक की एक लंबी प्रक्रिया थी। लेकिन मैं इस दर्द के लिए आभारी हूं - इसलिए मैंने अधिक कोड उत्पन्न करना और विकास के एक पुनरावृत्ति में कम गलतियाँ करना सीखा।

दर्द 5: विंडोज और कुछ नहीं बल्कि विंडोज

उस समय, .NET अभी भी विंडोज के लिए एक विकास मंच के रूप में तैनात है। हां, एक मोनो परियोजना थी, जो, संक्षेप में, लिनक्स पर .NET की "साइकिल" थी, लेकिन यह मुख्य फ्रेमवर्क का एक वैकल्पिक संस्करण था, और अभी भी परियोजना पृष्ठ www.mono-project.com/docs/ पर है। लगभग-मोनो / अनुकूलता ) उन विशेषताओं को सूचीबद्ध करता है जो फ्रेमवर्क के संस्करण द्वारा इसमें नहीं जोड़े जाते हैं। जब आपने लिनक्स के लिए कुछ विकसित किया, तो यह उपयोगकर्ता के अनुकूल था, क्योंकि मोनो के पास वह समर्थन और समुदाय नहीं था, और यदि आप कुछ असत्य चीजों में बदल गए, तो कोड बस टूट सकता है। यही है, यदि आप शुरू में मोनो के लिए इसे विकसित नहीं करते हैं, तो आप सिद्धांत रूप में प्लेटफ़ॉर्म-स्वतंत्र कोड नहीं लिख सकते हैं। मैं संपूर्ण रूप से .NET के विकास के लिए इस परियोजना के महत्व को बाहर नहीं करता, क्योंकि इसके बिना कोर प्रकट नहीं होता था, लेकिन व्यक्तिगत रूप से, मुझे इसके साथ कोई मुकाबला अनुभव नहीं था।

पेशेवरों की आयु (दर्द निवारक)

उनकी परियोजनाओं में शुद्ध .NET नवीनतम संस्करण का बहुत उपयोग इन सभी समस्याओं को समाप्त करता है। अब फ्रेमवर्क में कई प्लस हैं, लेकिन फिर हम कोर के लिए बाध्यकारी के साथ फायदे के बारे में बात करेंगे मैंने उसके साथ काम किया।

प्लस 1: प्रदर्शन

जब .NET कोर दिखाई दिया, तो यह संभव हो गया कि परिचित ऑपरेशन ज्यादा ठंडा और तेज हो। इस पर अंतिम एप्लिकेशन .NET फ्रेमवर्क पर अपने समकक्षों की तुलना में 5000 गुना तक कुछ डेटा के अनुसार काम करते हैं। लेकिन संकलन और लॉन्चिंग कभी-कभी अधिक समय लेते हैं - "लंबे समय तक दोहन - तेज ड्राइव।"

प्लस 2: क्रॉस-प्लेटफॉर्म

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

प्लस 3: सब कुछ के Async

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

प्लस 4: पुस्तकालयों को उतारना और कम गहन मेमोरी खपत

यदि आप C # के वर्तमान 8 वें संस्करण को देखते हैं, तो इसमें बहुत अधिक चीनी है, और परिवर्तन आकर्षक हैं। पहले, इससे पहले कि हमारे पास प्रारंभ में अनलोड किए गए DLL को गतिशील रूप से अनलोड करने की क्षमता नहीं थी (हमने परियोजना में पुस्तकालयों को गतिशील रूप से लोड किया था, लेकिन वे स्मृति में लटका रहे)। 3 जी कोर की रिहाई के साथ, लक्ष्यों के आधार पर पुस्तकालयों को गतिशील रूप से लोड और अनलोड करना संभव हो गया। उदाहरण के लिए, यदि हम एक फ़ाइल खोज एप्लिकेशन बनाना चाहते हैं, और उपयोगकर्ता XML एक्सटेंशन का चयन करता है, तो हम डायनामिक रूप से XML पार्सर को दस्तावेज़ों में लोड करते हैं और इसके पेड़ में खोजते हैं। अगर हम JSON द्वारा खोज करना चाहते हैं, तो हम इसके शरीर - पुस्तकालयों द्वारा खोजना शुरू करते हैं जो कुछ शर्तों पर निर्भर हैं, और उन्हें RAM में रखने की कोई आवश्यकता नहीं है। और हाँ। अनुप्रयोग ने लगातार मेमोरी का उपभोग करना बंद कर दिया है। जब हम असेंबली को अनलोड करते हैं, तो हम इस असेंबली से जुड़े सभी संसाधनों को मुक्त कर देते हैं।

प्लस 5: ट्यूपल्स

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

संक्षेप में!

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

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