ब्लेज़र: एक घटक को बीमार होने से रोकने के लिए या मार्कअप से अलग कोड के लिए दो दृष्टिकोण कैसे करें

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

विशेष रूप से, यह संभवतः एक पैटर्न है, लेकिन एक बहुत अच्छा नियम यह है कि मार्कअप को कोड से अलग किया जाना चाहिए। यह अच्छे पुराने वेब फॉर्मों पर लागू होता है, Asp.Net MVC - क्या कोई अन्य रेजर पर मार्कअप लिखता है?), और कोणीय एक कठोर उद्यम में लोकप्रिय है।

यदि आप लंबे समय तक एंडर्स के सामने के बारे में निराशा से चले गए हैं और नए-नए उलझी हुई कोणीय और प्रतिक्रिया के लिए चले गए हैं, तो ...

हाँ, सज्जनों, बैकएंड डेवलपर्स, हमें फिर से आशा थी कि वर्षों में अर्जित ज्ञान सिर में नहीं खो जाएगा। और वह आशा है Microsoft की Blazor तकनीक।
ब्लेज़र परियोजना बनाते समय स्टूडियो द्वारा बनाई गई डिफ़ॉल्ट परियोजना को खोलने, और फिर कई लेखों को देखने के बाद, मैंने सोचा कि सब कुछ वास्तव में इतना बुरा है और कोड और मार्कअप हमेशा एक ही फाइल में होते हैं, उदाहरण के लिए यहां (इसके बाद सभी उदाहरणों के आधार पर दिखाया जाएगा। Visual Studio 2019 से ब्लेज़र सर्वर ऐप टेम्पलेट प्रोजेक्ट .Net कोर 3.1 के साथ स्थापित):

यहाँ कुछ भी नहीं भ्रमित?

मेरी राय में, लाल रंग से भरी हर चीज का उस सामग्री से बहुत कम लेना-देना है जो इस घटक का प्रतिनिधित्व करती है और आपको इससे छुटकारा पाने की आवश्यकता है। क्यों?

1. खैर, सबसे पहले, फ्रंट-एंड डेवलपर जो इस नियंत्रण पर एक ही समय में आपके साथ काम करेगा, प्रतीकों से थोड़ा भ्रमित होगा जो उसके लिए समझ से बाहर है और हर बार वह सतर्क होगा और आपसे सवाल पूछेगा जब उसे रेजर मार्कअप द्वारा तैयार किए गए कोड के टुकड़े में कुछ बदलना होगा। ।
2. बेशक, सामने वाले सावधान रहेंगे, लेकिन यह सुनिश्चित करने के लिए कि आप समय-समय पर इस तथ्य का सामना करेंगे कि कुछ जोड़तोड़ के बाद, आपका पृष्ठ आपके अपेक्षा के अनुरूप काम नहीं करेगा या बस काम नहीं करेगा।
3. अगर आपको लगता है कि फ्रंट-एंड डेवलपर्स की जरूरत नहीं होगी, क्योंकि सब कुछ अब सी # में लिखा जा सकता है, तो आप गलत हैं। किसी भी मामले में, आपको नियंत्रण को स्टाइल करने की आवश्यकता है और यह या तो फ्रंट-एंड डेवलपर द्वारा किया जाएगा, या टाइपसेट्टर द्वारा जो अक्सर नहीं जानता कि सी # क्या है।
4. सबसे पहले ऐसा लगेगा कि यह कोड छोटा है और यह लेआउट को बहुत अधिक अव्यवस्थित नहीं करता है, यह एक भ्रामक है, एक बढ़ती परियोजना में आप बहुत जल्दी मंच, तकनीकी डेमो से "लानत है कि यहां क्या होता है" जाएगा। एक बार से अधिक मैं इस तथ्य पर आया था कि SQL वेब नियंत्रण से या सीधे .cshtml पृष्ठ पर, डेटाबेस के लिए एक SQL क्वेरी पोस्ट की गई थी, हां, मैं मजाक नहीं कर रहा हूं। बहुत बार, अनुभवी डेवलपर्स जिन्होंने कल आपको एक सामाजिक सुरक्षा साक्षात्कार में प्रताड़ित किया था, जो पहले से ही ठोस सिद्धांतों को जानते हुए, कल मार्कअप में व्यवसाय तर्क लिख रहे हैं।

मुझे लगता है कि मैंने आपको पहले ही काफी डरा दिया है, अब मैं आपको बताता हूं कि उपरोक्त समस्याओं से कैसे बचा जाए, यह सब बहुत सरलता से किया जाता है। और यह बहुत अच्छा होगा यदि आप किसी नए रेजर घटक को बनाते समय एक नियम के रूप में निम्नलिखित दृष्टिकोण लेते हैं। तो, पहला दृष्टिकोण।

आधार वर्ग

पहला और हाल ही में, केवल दृष्टिकोण तक।

आप एक आधार वर्ग बनाते हैं जिसमें सभी प्रदर्शन तर्क स्थित होंगे, ऊपर दिए गए उदाहरण से नियंत्रण के लिए। टेम्पलेट का उपयोग करके एक नई फ़ाइल बनाएँ
[नियंत्रण का नाम] .razor.cs

यहां स्टूडियो हमारी सहायता के लिए आएगा और नीचे दी गई तस्वीर में दो फाइलों से कुछ का निर्माण करेगा:

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

यदि आप अभी एक नई फ़ाइल खोलते हैं, तो FetchData वर्ग का नाम लाल लहरदार रेखा के साथ रेखांकित किया जाएगा, सब कुछ सत्य है, क्योंकि इस तथ्य के बावजूद कि FetchData.razor में आप कहीं भी FetDData नाम के साथ वर्ग घोषणाएँ नहीं देखेंगे, बाद में परियोजना को संकलित करने के बाद यह दिखाई देगा, मैं दिखाऊंगा यह कम है, और इसलिए वर्ग नाम FetchData पहले से ही आरक्षित है। हमारे पास कन्वेंशन का उपयोग करने के अलावा और कोई विकल्प नहीं है कि हम FetchDataBase क्लास में डिस्प्ले लॉजिक (और केवल यह !!!) लगा देंगे, यानी टेम्प्लेट द्वारा क्लास का नाम बन जाएगा:
[नियंत्रण नाम] आधार

बेशक, आप भ्रमित हो सकते हैं और अपने स्वयं के स्थिर विश्लेषक लिख सकते हैं, जो प्रत्येक घटक के लिए ऐसी फ़ाइलों की जांच करेगा, क्यों नहीं?
अगला, हमें इस श्रेणी को ComponentBase से इनहेरिट करने की आवश्यकता है। जोड़ना मत भूलना
Microsoft.AspNetCore.Compords का उपयोग करना ;

और यहाँ है कि हम क्या मिला:

वाह, कक्षा यहां प्रदर्शन तर्क को स्थानांतरित करने के लिए तैयार है, जिसे अब हमें C # में पूरी तरह से लिखने का अवसर मिला है, क्या यह खुशी नहीं है? :)

लेकिन जबकि रेजर घटक को हमारी फाइल के बारे में कुछ भी नहीं पता है, केवल विजुअल स्टूडियो को पता है कि उनके पास कुछ सामान्य है।

तो, निम्न चाल करें:

हमें FetchDataBase वर्ग से रेजर घटक विरासत में मिला है।

बता दें कि C # कोड जो अभी भी FetchData.raz में मौजूद है, आपको परेशान नहीं करता है।

अभी, हम सभी डिस्प्ले लॉजिक को फाइल के पीछे हमारे तथाकथित कोड में ट्रांसफर करेंगे:

क्या हुआ, ठीक है, सबसे पहले हमने प्रयोग करके जोड़ा-और। रेजर नियंत्रण पर, आप व्यावहारिक रूप से उन्हें नहीं देखेंगे, क्योंकि यह उन्हें _Imports.razor में जोड़ने के लिए प्रथागत है। वहाँ पहले से ही सबसे अधिक इस्तेमाल में से कुछ जोड़ रहे हैं।

अगला, हम संपत्ति के माध्यम से इंजेक्ट करते हैं, जैसा कि आप देख सकते हैं, हमारा पसंदीदा DI ठीक काम करता है।
आपको केवल [Inject] विशेषता के साथ कार्यान्वित संपत्ति को चिह्नित करने की आवश्यकता है। रेजर घटक में, इसे इंजेक्ट किया गया था। यही है, परिवर्तन न्यूनतम हैं।

ठीक है, तो संपत्ति का अनुसरण करता है, जिसमें हम प्रदर्शित जानकारी लोड करते हैं, इसे कम से कम संरक्षित किया जाना चाहिए (क्योंकि रेजर नियंत्रण वर्तमान वर्ग से विरासत में मिला है)। या सार्वजनिक यदि आप इसे बाहर से शुरू करना संभव बनाने का निर्णय लेते हैं, तो इस मामले में आपको इसे [पैरामीटर] विशेषता के साथ चिह्नित करना होगा। ब्लेज़र के पुराने संस्करणों में, यह काफी संरक्षित था, लेकिन अब स्टूडियो विश्लेषक आपको इसके लिए डांटेंगे।

सिद्धांत रूप में, आप इस वर्ग में एक कंस्ट्रक्टर जोड़ सकते हैं और वहां कुछ काम कर सकते हैं, लेकिन यह अनुशंसित नहीं है, OnInitializedAsync () विधि में सभी आरंभीकरण तर्क रखना बेहतर है

वह सब FetchData.razor में रहता है

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

सबसे महत्वपूर्ण बात यह है कि क्या यह बिल्कुल काम करता है, अब आइए देखें:

महान, ऐसा लगता है जैसे उन्होंने कुछ भी नहीं तोड़ा =)

आंशिक वर्ग

और इसलिए दूसरा दृष्टिकोण, जो हाल ही में दिखाई दिया ( https://docs.microsoft.com/en-us/aspnet/core/blazor/compenders?view=aspnetcore-3.1#partial-class-support ), लेकिन सबसे अधिक संभावना पूरी तरह से बदल जाएगी पिछला वाला। श्रमिकों के अनुरोध पर .Net कोर 3.1 ने रेजर नियंत्रणों के लिए एक आंशिक वर्ग बनाने की क्षमता को जोड़ा। इसलिए, हम लगभग सब कुछ छोड़ देते हैं क्योंकि यह पिछले दृष्टिकोण में है, लेकिन अब हमें ComponentBase से विरासत में प्राप्त करने की आवश्यकता नहीं है, और वर्ग को घटक के समान कहा जा सकता है, अर्थात, इसका हस्ताक्षर निम्नानुसार होगा:
सार्वजनिक आंशिक वर्ग [कॉम्पोनेन्टनाम]

जैसा कि आप नीचे देख सकते हैं, परिवर्तन कम से कम हैं, पीछे के कोड में हमें CompaseBase से विरासत से छुटकारा मिला और वर्ग को आंशिक रूप में चिह्नित किया गया

मार्कअप फ़ाइल भी थोड़ी सरल है, हमने FetchDataBase से विरासत से भी छुटकारा पा लिया, यह वर्ग अपनी बेकारता के कारण अस्तित्व में नहीं आया।

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

यह परिचित है, यह नहीं है?) हर कोई जो एक बार अपने रेज़र Asp.Net MVC घटकों को बनाते हैं, उन्हें ऑटो-जनरेटेड फ़ाइल की सामग्री बहुत परिचित होगी।

मुझे आशा है कि आपने हज़र पर मेरे पहले लेख से आज ब्लेज़र के बारे में थोड़ा और जान लिया है। आलोचनाओं, प्रश्नों और नए लेखों के अनुरोधों को छोड़ दें =)