बड़ी परियोजनाओं में ASP.NET MVC। परिचय: मॉडल बाइंडिंग

ज्वाइन करने के बजाय

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

हालाँकि, शुरुआत के लिए आपको अभी भी सिद्धांत के साथ थोड़ा तड़पाना होगा।

सबसे पहले, कुछ शब्दों को परिभाषित करते हैं:

• प्रस्तुतकर्ता तर्क परत है जो दृश्य को नियंत्रित करता है। MVP टेम्पलेट से "क्रॉप्ड" प्रस्तुतकर्ता के आधार पर। खतना कैसे हुआ यह बाद में स्पष्ट होगा। मैं केवल यह कह सकता हूं कि ViewModel शब्द का उपयोग अक्सर किया जाता है (जैसा कि, उदाहरण के लिए, उपरोक्त लेख में), लेकिन हमारे पास एक विशिष्ट ViewModel (और एक सामान्य प्रस्तुतकर्ता से छोटा) की तुलना में कुछ अधिक होगा, इसलिए मैंने इसका उपयोग करने से इनकार कर दिया।
• ऊपरी स्तर की वस्तु, ओवीयू - इसे निम्नलिखित भागों में बेहतर समझा जाएगा। संक्षेप में, OVU एक मॉडल, प्रस्तुतकर्ता या दृश्य है जिसे सीधे नियंत्रक से कहा जाता है
• देखें, प्रस्तुति - अजीब तरह से, इस शब्द को भी कभी-कभी स्पष्ट करना पड़ता है। ASP.NET MVC में व्यू के अनुसार, मेरा मतलब प्रस्तोता का संयोजन और रेजर का उपयोग करके लिखा गया टेम्पलेट है

दूसरे, कुछ परिचयात्मक:

1. हमारी परियोजना में, हम अपने जीवन को सभी प्रकार के ऑटोपापर और ओआरएम के साथ सरल नहीं करेंगे।
   
   सामान्य तौर पर, यह एक अच्छा अभ्यास है यदि आप गति में कुछ महत्वपूर्ण कर रहे हैं। चूंकि मैं उन परियोजनाओं पर काम करता हूं जहां क्वेरी निष्पादन समय (HTTP और SQL दोनों) महत्वपूर्ण है, जो कि मैं ज्यादातर मामलों में खर्च कर सकता हूं, डेटाबेस से ऑब्जेक्ट्स को सबसे सरलीकृत नियमों के साथ संस्थाओं को मैप कर रहा है। इसके लिए मैं Dapper.NET पर अपने स्वयं के आवरण का उपयोग करता हूं
2. टीके के अनुसार, हमारे पास बड़ी संख्या में मॉड्यूल हैं जो कि असंतुष्ट कार्यक्षमता के साथ हैं। प्रत्येक नियंत्रक, अनुप्रयोग का प्रत्येक घटक बाकी हिस्सों से बहुत अलग है। व्यवहार में, इसका मतलब है कि कॉपी-पेस्ट और कोड पीढ़ी का उपयोग करके प्राप्त समय इन क्रियाओं के परिणामों को परिष्कृत करने में लगने वाले समय से अधिक नहीं है
3. हमारे विचारों में तर्क की एक बड़ी मात्रा शामिल होगी । ज्यादातर यह निस्संदेह प्रस्तुतकर्ता में टेम्पलेट से बाहर ले जाया जाएगा, लेकिन, दुर्भाग्य से, इसे पूरी तरह से छुटकारा पाना संभव नहीं होगा।
4. आवेदन में काफी कड़े ब्राउज़र समर्थन आवश्यकताएँ हैं। इसका मतलब है कि हमें CSS चयनकर्ताओं के उपयोग को कम करना चाहिए और JS को अक्षम होने पर कार्यक्षमता बनाए रखते हुए "विनीत जावास्क्रिप्ट" का उपयोग करना चाहिए

मॉडल डेटा बाइंडिंग

काश, आगे बढ़ने से पहले, हमें मोटे तौर पर यह समझने की ज़रूरत है कि ASP.NET MVC में डेटा बाइंडिंग तंत्र कैसे काम करता है और इससे जुड़ी कुछ समस्याओं पर विचार करता है।

HtmlHelper वर्ग आपके पृष्ठ के लिए HTML मार्कअप बनाने के तरीकों का प्रतिनिधित्व करता है। उनमें से ज्यादातर फॉर्म कंट्रोल टैग (इनपुट, लेबल, आदि) से जुड़े हैं। वे हमारे हित हैं
इन विधियों को दो श्रेणियों में विभाजित किया जा सकता है, चलो उन्हें "संक्षेप में जनरेटर" और "अभिव्यक्ति में जनरेटर" कहते हैं। उदाहरण के लिए, टेक्स्ट फ़ील्ड आउटपुट विधि (<इनपुट प्रकार = "टेक्स्ट" />) लें।

संक्षेप में जनरेटर Html.TextBox () विधि है। वास्तव में, इसका डेटा बाइंडिंग से कोई लेना-देना नहीं है - आप इसे स्वयं भरते हैं, आप इसका वर्तमान मूल्य निर्दिष्ट करते हैं।

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

यह क्या देता है?

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

1. इस दृश्य का उपसर्ग वर्तमान दृश्य के ViewData से लिया गया है (उस पर और अधिक)
2. अभिव्यक्ति से एक रेखा उत्पन्न होती है जो मॉडल को कॉल किए बिना पारित फ़ंक्शन के कोड को दोहराती है।
   उदाहरण के लिए, से
   

   Html.TextBoxFor(m => m.SomeArray[someIndexer])

   someIndexer = 2 के साथ हमें स्ट्रिंग "SomeArray [2]" मिलता है।
   

   मैं यह नहीं बताऊंगा कि यह वास्तव में कैसे काम करता है, आप इसे स्वयं स्रोत कोड में देख सकते हैं। लेकिन एक महत्वपूर्ण बिंदु है:
   अभिव्यक्ति सही ढंग से केवल क्षेत्र <3 की गहराई से उत्पन्न होती है
   यानी अभिव्यक्ति

   Html.TextBoxFor(m => m.SubModel.SomeArray[someIndexer])

   पहले से काम नहीं हो सकता है

3. चरण 1 में प्राप्त उपसर्ग, यदि कोई हो, चरण 2 में प्राप्त स्ट्रिंग के साथ संयुक्त है। परिणाम परिणामी टैग के नाम फ़ील्ड का मूल्य है।
4. इस मूल्य में आगे सभी वर्ण ',', '[', ']' को अंडरस्कोर ('_') से बदल दिया गया है। यह आईडी फ़ील्ड का मान है।

जैसा कि मैंने वादा किया था, विचार करें कि प्रस्तुति उपसर्ग कहाँ से आता है।
जब आप नियंत्रक से यह (।) कॉल करके एक दृश्य उत्पन्न करते हैं, तो ViewDataDictionary वर्ग का एक नया ऑब्जेक्ट बनाया जाता है। इसमें एक TemplateInfo फ़ील्ड है जो HtmlFieldPrefix स्ट्रिंग को संग्रहीत करता है। यह वर्तमान दृश्य का उपसर्ग है। डिफ़ॉल्ट रूप से, यह खाली है।
इसके अलावा, ASP.NET MVC में एक दृश्य से दूसरे को कॉल करने के दो तरीके हैं - या तो इसे पूरी तरह से अलग संदर्भ में निष्पादित करें (जैसा कि HtmlHelper.Partial () करता है), या इसे वर्तमान के "सबव्यू" के रूप में प्रस्तुत करें - ये HtmlHelper.DisplayFor () और HtmlHelper तरीके हैं .EditorFor ()।
दूसरा मामला दिलचस्प है। इन विधियों को कॉल करना व्यक्तिगत टैग के लिए अभिव्यक्ति द्वारा जनरेटर को कॉल करने के समान है, लेकिन परिणामस्वरूप टैग के बजाय, हमें एक नया टेम्पलेट उपसर्ग के साथ प्रदान किया गया एक दृश्य मिलता है।

एक छोटा सा उदाहरण

नियंत्रक से कहा जाता है MainView.cshtml टेम्पलेट के साथ एक दृश्य हो:

@model App.Models.MainModel
<h1>MainView.cshtml</h1>

@using (this.Html.BeginForm())
{
this.Html.TextBoxFor(m => m.SomeText)
this.Html.EditorFor(m => m.SubModel, "SubView")
}

और दृश्य / साझा / EditorTemplates में पड़े SubView.cshtml टेम्पलेट के साथ दृश्य:

@model App.Models.SubModel
<h2>SubView.cshtml</h2>

this.Html.TextBoxFor(m => m.SubText)

प्रतिपादन निम्नलिखित टैग में परिणाम होगा:

1. <input type = "text" id = "SomeText" नाम = "SomeText" />
2. <input type = "text" id = "SubModel_SubText" नाम = "SubModel.SubText />>

जैसा कि हम देख सकते हैं, SubModel उपसर्ग को HtmlHelper.EditorFor () विधि के लिए दिए गए अभिव्यक्ति के अनुसार, SubView में पारित किया गया था।


तो, मार्कअप प्रदान किया जाता है, क्लाइंट ने डेटा दर्ज किया, अनुरोध सर्वर को भेजा जाता है। अब हम विचार करेंगे कि प्राप्त डेटा को कैसे संसाधित किया जाता है और मॉडल में बदल दिया जाता है (हम मॉडल के उपयोगकर्ता वर्ग होने पर मामले पर विचार करेंगे)।

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

   महत्वपूर्ण: निर्माणकर्ता को डिफ़ॉल्ट होना चाहिए, जिसमें पैरामीटर नहीं हैं। वैकल्पिक पैरामीटर विफल हो जाएंगे

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

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

निष्कर्ष

यह संक्षिप्त सैद्धांतिक हिस्सा है, हमने ASP.NET MVC का प्रभावी ढंग से उपयोग करना शुरू करने के लिए न्यूनतम आवश्यक सीखा है, और हम अभ्यास करना शुरू कर सकते हैं