ViewState की वास्तविक समझ

एक अनुवादक से: यह ASP.NET डेवलपर्स में से एक से एक लेख का अनुवाद है, जो पृष्ठ स्थिति का प्रबंधन करने के लिए तंत्र का विवरण देता है - ViewState। इस तथ्य के बावजूद कि लेख 2006 में लिखा गया था, फिर भी इसकी प्रासंगिकता नहीं खोई है।

ViewState एक बहुत ही अजीब प्राणी है। मैं सभी प्रकार की अफवाहों पर विराम लगाने का प्रयास करूंगा, और यह समझाने की कोशिश करूंगा कि व्यूस्टेट का तंत्र वास्तव में कैसे काम करता है, शुरू से आखिर तक, इसे विभिन्न दृष्टिकोणों से देखते हुए।

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

ऐसा नहीं है कि ViewState के बारे में जानकारी का कोई अच्छा स्रोत नहीं है, वे बस कुछ याद करते हैं, और इस तरह केवल ViewState के आसपास सामान्य उथल-पुथल में योगदान करते हैं। उदाहरण के लिए, प्रमुख बिंदुओं में से एक यह समझ रहा है कि ViewState का ट्रैकिंग कैसे काम करता है। और यहां ViewState के बारे में एक बहुत अच्छा और गहरा लेख है, जो इस बात की चिंता भी नहीं करता है! या यहां W3Schools पर एक लेख है जो बताता है कि सर्वर को भेजे गए फॉर्म पैरामीटर व्यूस्टेट में संग्रहीत किए जाते हैं, जो सच नहीं है। (मेरा विश्वास मत करो। उनके उदाहरण पर ViewState पाठ को अक्षम करें और इसे फिर से चलाएँ)। और यहां MSDN प्रलेखन है जो बताता है कि पोस्टबैक के बीच नियंत्रण उनके राज्य को कैसे संग्रहीत करता है। यह कहना नहीं है कि यह दस्तावेज़ गलत है, लेकिन इसमें एक कथन है जो पूरी तरह से सही नहीं है:

"यदि कोई नियंत्रण किसी छिपे हुए फ़ील्ड के बजाय किसी संपत्ति के लिए ViewState का उपयोग करता है, तो ग्राहक को प्रतिक्रियाएं भेजने के बीच यह संपत्ति स्वचालित रूप से बच जाएगी।"

ऐसा लगता है कि यहां यह समझा जाता है कि ViewState में जो कुछ भी देखा जाता है वह क्लाइंट को भेजा जाएगा। गलत! यह स्पष्ट है कि ViewState के आसपास यह उथल-पुथल कहाँ से आता है। इंटरनेट पर कहीं भी मुझे उनके काम का 100% पूर्ण और सटीक विवरण नहीं मिल सका! मैंने देखा सबसे अच्छा लेख स्कॉट मिशेल द्वारा एक लेख है । इसे पढ़ना आवश्यक है। हालाँकि, यह ViewState के प्रारंभ और ट्रैकिंग के दौरान माता-पिता और बच्चे के नियंत्रण की बातचीत की व्याख्या नहीं करता है, और यह पहले से ही ViewState की बहुत सी गलतफहमियों का कारण बनता है, कम से कम मेरे अनुभव के आधार पर।

तो इस लेख का पहला लक्ष्य यह है कि ViewState कैसे शुरू से अंत तक संभवतः अन्य लेखों द्वारा छोड़े गए सफेद धब्बों को कवर करता है, का एक संपूर्ण विवरण देना है। ViewState प्रक्रिया के विस्तृत विवरण के बाद, मैं कुछ त्रुटियों को दिखाऊंगा जो डेवलपर्स ViewState का उपयोग करते समय करते हैं, आमतौर पर इसे साकार किए बिना भी, और इन त्रुटियों को कैसे ठीक किया जाए। यह ध्यान दिया जाना चाहिए कि मैंने यह लेख ASP.NET 1.x पर आधारित लिखा है। हालाँकि, ASP.NET 2.0 में ViewState इंजन में बहुत कम परिवर्तन हैं। विशेष रूप से, एक नया प्रकार का ViewState दिखाई दिया है - ControlState, हालांकि यह ViewState की तरह ही उपयोग किया जाता है, इसलिए हम बस इसे अनदेखा कर सकते हैं।

पहले मुझे समझाने की वजह से मुझे लगता है कि ViewState के सार को समझना बहुत महत्वपूर्ण है:

ViewState की गलतफहमी की ओर जाता है ...

1. महत्वपूर्ण जानकारी का नुकसान
2. ViewState पर हमलों
3. खराब प्रदर्शन - कोई प्रदर्शन तक नहीं
4. खराब एक्स्टेंसिबिलिटी - यदि आप प्रत्येक अनुरोध के साथ 50k भेजते हैं, तो आप कितने उपयोगकर्ताओं की सेवा कर सकते हैं?
5. सामान्य रूप से खराब डिजाइन
6. सिरदर्द, मतली, चक्कर आना और अतिसारी मेहराब के आकार की अपरिवर्तनीय विकृति।

अब, चलो शुरू से ही शुरू करते हैं।

ViewState क्या करता है?

यह ViewState के मुख्य कार्यों की एक सूची है। उनमें से प्रत्येक एक विशिष्ट उद्देश्य पूरा करता है। आगे हम विचार करेंगे कि वे इन लक्ष्यों को कैसे प्राप्त करते हैं।

1. एक हैश तालिका के रूप में कुंजी नियंत्रण डेटा बचाता है
2. मॉनिटर दृश्य स्थिति परिवर्तन
3. ग्राहक पर एक छिपे हुए क्षेत्र में संग्रहीत डेटा को सीरियल करता है और उसे निष्क्रिय करता है
4. पोस्टबैक पर डेटा को स्वचालित रूप से पुनर्स्थापित करता है

यह समझना और भी महत्वपूर्ण है कि ViewState क्या नहीं करता है।

ViewState क्या नहीं करता है?

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

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

1. ViewState डेटा बचाता है

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

ViewState[ "Key1" ] = 123.45M; // decimal

ViewState[ "Key2" ] = "abc" ; // string

ViewState[ "Key3" ] = DateTime .Now; // DateTime

* This source code was highlighted with Source Code Highlighter .

वास्तव में, यहां "ViewState" सिर्फ एक नाम है। ViewState System.Web.UI.Control वर्ग से परिभाषित एक संरक्षित संपत्ति है जिसमें से सर्वर नियंत्रण, उपयोगकर्ता नियंत्रण और पृष्ठों सहित सभी नियंत्रण विरासत में मिले हैं। इस संपत्ति का प्रकार System.Web.UI.StateBag है । कड़े शब्दों में, StateBag क्लास का ASP.NET से कोई लेना-देना नहीं है। यह System.Web असेंबली में परिभाषित किया गया है, लेकिन System.Web.UI में परिभाषित स्टेट फॉर्मैटर पर निर्भर होने के अलावा, स्टेटबाग के लिए कोई भी शर्त नहीं है कि सिस्टम नेमस्पेस में ArrayList के रूप में उसी स्थान पर परिभाषित नहीं किया जाएगा। संग्रह। व्यवहार में, सर्वर नियंत्रण सबसे अधिक स्टोर करने के लिए ViewState का उपयोग करते हैं, यदि सभी नहीं, तो उनके गुणों का। यह Microsoft से लगभग सभी तैयार-किए गए नियंत्रणों (जैसे लेबल, टेक्स्टबॉक्स, बटन) के लिए सही है। यह महत्वपूर्ण है! आपके द्वारा उपयोग किए जाने वाले नियंत्रणों के बारे में आपको ऐसी बातें पता होनी चाहिए। इस वाक्य को फिर से पढ़ें। गंभीरता से ... और एक तीसरी बार: सर्वर नियंत्रण सबसे अधिक स्टोर करने के लिए ViewState का उपयोग करते हैं, यदि सभी नहीं, तो उनके गुणों का । अपने अनुभव के आधार पर, गुणों के बारे में सोचकर, आप शायद कुछ इस तरह की कल्पना करते हैं:

public string Text
{
get { return _text; }
set { _text = value ; }
}

* This source code was highlighted with Source Code Highlighter .

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

public string Text
{
get { return ( string )ViewState[ "Text" ]; }
set { ViewState[ "Text" ] = value ; }
}

* This source code was highlighted with Source Code Highlighter .

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

public class MyClass
{
private string _text = "Default Value!" ;

public string Text
{
get { return _text; }
set { _text = value ; }
}
}

* This source code was highlighted with Source Code Highlighter .

डिफ़ॉल्ट मान ऐसा है, क्योंकि यह संपत्ति है जो इसे लौटाता है अगर इसे कभी भी कुछ भी नहीं सौंपा गया है। हम समान व्यवहार कैसे प्राप्त करते हैं, लेकिन ViewState का उपयोग करते हुए? और यहाँ है कैसे:

public string Text
{
get
{
return ViewState[ "Text" ] == null ?
"Default Value!" :
( string )ViewState[ "Text" ];
}
set { ViewState[ "Text" ] = value ; }
}

* This source code was highlighted with Source Code Highlighter .

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

2. ViewState ट्रैक बदलता है

क्या आपके साथ कभी ऐसा हुआ है कि आपने नियंत्रण की संपत्ति के लिए कुछ मूल्य विनियोजित किया और फिर आपको ऐसा लगा जैसे कि ... गंदा? यह निश्चित रूप से मेरे साथ हुआ। इसके अलावा, कार्यालय की स्थापना के गुणों में बीस घंटे के बाद मैं इतना गंदा है कि मेरी पत्नी ने मुझे चूमने के लिए, अगर केवल मैं फूल नहीं लाए गंध मुखौटा से इनकार कर दिया बन गया। ईमानदार शब्द! ठीक है, ठीक है, सेटिंग गुण आपको गंदा नहीं करता है। लेकिन वह एक गंदा स्टेटबाग बनाता है! स्टेटबाग सिर्फ एक हैश टेबल की तरह कुंजियों और मूल्यों का एक गूंगा संग्रह नहीं है, (हैश तालिका को मैंने इसे क्या कहा है, यह गुस्से में डरावना नहीं है)। प्रमुख मूल्यों को संचय करने के अलावा, स्टेटबग परिवर्तन को ट्रैक कर सकता है (इसके बाद "ट्रैकिंग" - लगभग प्रति)।)। ट्रैकिंग या तो चालू या बंद है। TrackViewState () विधि को कॉल करके इसे चालू किया जा सकता है, लेकिन यदि आप इसे चालू करते हैं, तो आप इसे बंद नहीं कर सकते। जब और केवल जब ट्रैकिंग चालू हो, तो किसी भी स्टेटबाग रिकॉर्ड में कोई भी परिवर्तन इस रिकॉर्ड को "डर्टी" (इसके बाद "गंदा" - लगभग) के रूप में चिह्नित करेगा। स्टेटबाग के पास एक विशेष विधि भी है जो सत्यापन के लिए आवश्यक है, और रिकॉर्ड गंदा है - IsItemDirty (स्ट्रिंग कुंजी)। आप SetItemDirty (स्ट्रिंग कुंजी) विधि को कॉल करके मैन्युअल रूप से रिकॉर्ड कर सकते हैं। इसे स्पष्ट करने के लिए, मान लें कि हमारे पास एक स्टेट रहित है:

stateBag.IsItemDirty( "key" ); // false
stateBag[ "key" ] = "abc" ;
stateBag.IsItemDirty( "key" ); // false

stateBag[ "key" ] = "def" ;
stateBag.IsItemDirty( "key" ); // false

stateBag.TrackViewState();
stateBag.IsItemDirty( "key" ); // , false

stateBag[ "key" ] = "ghi" ;
stateBag.IsItemDirty( "key" ); // TRUE!

stateBag.SetItemDirty( "key" , false );
stateBag.IsItemDirty( "key" ); // FALSE!

* This source code was highlighted with Source Code Highlighter .

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

stateBag[ "key" ] = "abc" ;
stateBag.IsItemDirty( "key" ); // false
stateBag.TrackViewState();
stateBag[ "key" ] = "abc" ;
stateBag.IsItemDirty( "key" ); // true

* This source code was highlighted with Source Code Highlighter .

कोई व्यक्ति ViewState लिख सकता है ताकि यह रिकॉर्ड करने के तरीके को निर्धारित करने से पहले नए और पुराने मूल्यों की जांच कर सके। लेकिन याद रखें कि ViewState आपको किसी भी ऑब्जेक्ट को मान के रूप में उपयोग करने की अनुमति देता है, जिसका अर्थ है कि हम तुच्छ स्ट्रिंग तुलनाओं के बारे में बात नहीं कर रहे हैं, और प्रत्येक वस्तु IComparable को लागू नहीं करती है। काश, क्योंकि वहाँ क्रमबद्धता और deserialization है, जिस वस्तु को आप ViewState में रखते हैं, वही वस्तु पोस्टबैक के बाद नहीं होगी। ViewState को ऐसी तुलनाओं की आवश्यकता नहीं है, इसलिए यह नहीं है। यह ट्रैकिंग किस बारे में है।

लेकिन आप शायद सोच रहे हैं कि स्टेटबाग को इस सुविधा की आवश्यकता क्यों है। TrackViewState () को कॉल करने के बाद कोई परिवर्तन हुआ है तो किसी को अचानक यह जानने की आवश्यकता क्यों होगी? सिर्फ नियमित संग्रह का उपयोग क्यों न करें और समस्याओं को न जानें? और यह उन स्थानों में से एक है जो ViewState के आसपास सभी भ्रम का कारण है। मैंने कई ASP.NET विशेषज्ञों के साथ साक्षात्कार आयोजित किया जिनके पास अपने रिज्यूमे में इस तकनीक का उपयोग करने के वर्ष हैं, और वे यह साबित नहीं कर सके कि वे इस मुद्दे को समझते हैं। इसके अलावा, मैंने कभी ऐसे व्यक्ति का साक्षात्कार नहीं लिया जो यह जानता था! सबसे पहले, यह समझने के लिए कि ट्रैकिंग क्यों आवश्यक है, आपको थोड़ी गहराई से समझने की आवश्यकता है कि कैसे ASP.NET घोषणात्मक नियंत्रणों के साथ काम करता है। घोषणा-ये वो नियंत्रण हैं जो ASPX या ASCX फ़ाइलों में परिभाषित किए गए हैं:

< asp:Label id ="lbl1" runat ="server" Text ="Hello World" />

* This source code was highlighted with Source Code Highlighter .

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

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

3. सीरियलाइजेशन और डिसेरिएलाइजेशन

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

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

एक छोटा विषयांतर - इससे पहले कि हम समझें कि ASP.NET इस एन्कोडेड स्ट्रिंग को कैसे बनाता है, हमें पृष्ठ पर नियंत्रणों के पदानुक्रम को समझने की आवश्यकता है। कई अनुभवी डेवलपर्स यह नहीं जानते हैं कि पृष्ठ में नियंत्रणों का एक पेड़ होता है, क्योंकि वे सभी के साथ काम कर चुके हैं ASPX पृष्ठ और उन पर घोषित नियंत्रण ... लेकिन नियंत्रण में बच्चे हो सकते हैं जिनमें उनके बच्चे हो सकते हैं, और आदि यह नियंत्रण का एक पेड़ बनाता है, जिसके मूल में पृष्ठ ही निहित है। दूसरा स्तर ASPX पृष्ठ के शीर्ष स्तर पर घोषित किए गए तत्व हैं (आमतौर पर उनमें से बिल्कुल तीन हैं - शाब्दिक, जिसमें <form> टैग, HtmlForm से पहले सब कुछ शामिल है, जो कि रूप और उसके बच्चे हैं, और एक अन्य शाब्दिक, जिसमें सब कुछ शामिल है </ /> प्रपत्र>)। तीसरे स्तर पर उल्लिखित तत्वों में निहित नियंत्रण हैं, और इसी तरह। इन नियंत्रणों में से प्रत्येक का अपना ViewState है - StateBag वर्ग का अपना उदाहरण। एक संरक्षित SaveViewState विधि System.Web.UI.Control में घोषित की गई है। यह एक वस्तु देता है। Control.SaveViewState का कार्यान्वयन अपने ViewState (StateBag में एक SaveViewState () विधि) के समान विधि की एक कॉल है। इस विधि को पूरे पेड़ में प्रत्येक नियंत्रण पर पुनरावर्ती रूप से कॉल करके, ASP.NET एक ही संरचना के साथ एक और पेड़ बनाता है, लेकिन अब यह एक नियंत्रण पेड़ नहीं है, बल्कि एक डेटा ट्री है।

इस चरण के डेटा ने अभी तक उस रेखा को एक छिपे हुए क्षेत्र में नहीं बदल दिया है, यह केवल वस्तुओं का एक पेड़ है जिसे सहेजने की आवश्यकता है। और फिर सब कुछ अंत में एक साथ आता है ... क्या आप तैयार हैं? जब एक StateBag को अपने राज्य को बचाने और वापस करने की आवश्यकता होती है (StateBag.SaveViewState ()), यह केवल उन रिकॉर्ड्स के लिए करता है जिन्हें गंदे के रूप में चिह्नित किया गया है। यही स्टेटबाग के लिए ट्रैकिंग है। यही एकमात्र कारण है। लेकिन क्या कारण है! एक StateBag इसमें शामिल सभी रिकॉर्ड्स को संभाल सकता है, लेकिन डेटा को उसके प्राकृतिक, घोषित राज्य की तुलना में क्यों नहीं बदला गया है? उन्हें संसाधित करने का बिल्कुल कोई कारण नहीं है - वे वैसे भी बहाल हो जाएंगे जब ASP.NET पृष्ठ को पार्स करता है, अगले अनुरोध का जवाब देता है (वास्तव में, पृष्ठ को केवल एक बार पार्स करने से प्रक्रिया में, वर्ग संकलित होता है, जिसके साथ ASP.NET और फिर यह काम करता है)। और ASP.NET में इस छोटे अनुकूलन के बावजूद, दुरुपयोग के कारण अनावश्यक डेटा अभी भी ViewState में संग्रहीत है। बाद में मैं इस तरह की त्रुटियों के कुछ उदाहरण दिखाऊंगा।

कार्य

यदि आप इस जगह तक पढ़ते हैं - मेरी बधाई। यहाँ आपके लिए एक इनाम है। मान लीजिए कि हमारे पास दो लगभग समान ASPX फॉर्म हैं, Page1.aspx और Page2.aspx। प्रत्येक पृष्ठ पर केवल एक फॉर्म और एक लेबल होता है:

< form id ="form1" runat ="server" >
< asp:Label id ="label1" runat ="server" Text ="" />
</ form >

* This source code was highlighted with Source Code Highlighter .

वे बिल्कुल समान हैं, लेकिन थोड़ा अंतर है। Page1.aspx पर लेबल का पाठ सरल है - "एबीसी":

< asp:Label id ="label1" runat ="server" Text ="abc" />

* This source code was highlighted with Source Code Highlighter .

और Page2.aspx पर पाठ बड़ा, बहुत बड़ा है (अमेरिकी संविधान का प्रस्तावना):

< asp:Label id ="label1" runat ="server" Text ="We the people of the United States,
in order to form a more perfect union, establish justice, insure
domestic tranquility, provide for the common defense, promote the
general welfare, and secure the blessings of liberty to ourselves and
our posterity, do ordain and establish this Constitution for the United
States of America." />

* This source code was highlighted with Source Code Highlighter .

यदि आप Page1.aspx खोलते हैं, तो आप केवल "abc" देखेंगे। लेकिन आप पृष्ठ का HTML कोड देख सकते हैं, और आप कुख्यात छिपे हुए क्षेत्र _ViewState को एन्क्रिप्ट किए गए डेटा की एक स्ट्रिंग के साथ देखेंगे। इस रेखा के आकार पर ध्यान दें। अब Page2.aspx पेज को खोलें और आपको प्रस्तावना दिखाई देगी। अब पेज सोर्स खोलें और देखें कि _ViewState फ़ील्ड किस आकार का है। ध्यान दें, प्रश्न: क्या इन पंक्तियों के आकार समान हैं या नहीं? उत्तर देने से पहले, आइए कार्य को थोड़ा जटिल करें। आइए प्रत्येक पृष्ठ पर एक बटन जोड़ें:

< asp:Button id ="button1" runat ="server" Text ="Postback" />

* This source code was highlighted with Source Code Highlighter .

किसी भी हैंडलर को क्लिक पर नहीं लटकाया जाता है, इसलिए बटन पर क्लिक करने से पृष्ठ केवल "ब्लिंक" हो जाता है। अब प्रयोग को दोहराएं, लेकिन पृष्ठ के स्रोत कोड को देखने से पहले, बटन पर क्लिक करें। एक ही सवाल: क्या इन पंक्तियों के आकार समान हैं या नहीं? समस्या के पहले भाग का सही उत्तर इस प्रकार है - वे ही हैं! वे समान हैं क्योंकि इनमें से किसी भी ViewStates का लेबल्स के साथ कुछ भी लेना-देना नहीं है। यदि आप समझते हैं कि ViewState कैसे काम करता है, तो यह स्पष्ट होना चाहिए। ViewState की ट्रैकिंग शुरू होने से पहले पाठ की संपत्ति को घोषित मूल्य सौंपा गया है। इसका मतलब यह है कि यदि आपने स्टेटबाग में पाठ प्रविष्टि के डर्टी झंडे की जाँच की है, तो इसे ध्वजांकित नहीं किया जाएगा। SaveViewState () कहे जाने पर StateBag अनलिस्टेड एंट्रीज़ को अनदेखा कर देता है, इसलिए टेक्स्ट प्रॉपर्टी को किसी छिपे हुए फ़ील्ड में क्रमबद्ध नहीं किया जाता है। और चूंकि पाठ क्रमबद्ध नहीं है, और अन्य सभी मामलों में प्रपत्र बिल्कुल समान हैं, ViewState का आकार समान रहता है।

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

अब हम समझते हैं कि ASP.NET कैसे निर्धारित करता है कि किस डेटा को क्रमबद्ध किया जाना है। लेकिन हमें नहीं पता कि वह उन्हें कैसे सीरियल देती है। यह विषय इस लेख के दायरे से परे है (क्या आप असेंबली रेफरेंस याद कर रहे हैं?), लेकिन यदि आप रुचि रखते हैं, तो ASP.NET 1.x में ASPFormatter या ASP.NET 2.0 में ObjectStateFormatter के बारे में पढ़ें।

और यहां आखिरी चीज डिसराइजेशन है। यह स्पष्ट है कि यदि हम डेटा को वापस नहीं लाएंगे तो ये सभी ट्रिकी ट्रैकिंग और क्रमांकन बेकार हो जाएंगे। यह विषय भी इस लेख के दायरे से परे है, यह कहने के लिए पर्याप्त है कि पूरी प्रक्रिया सीधे ऊपर चर्चा की गई के विपरीत है। ASP.NET सर्वर पर भेजे गए _ViewState फ़ील्ड को पढ़कर और LosFormatter (v1.x) या ObjectStateFormatter (v2.0) का उपयोग करके इसे डिसेररलाइज़ करके ऑब्जेक्ट्स का एक ट्री बनाता है।

4. स्वचालित रूप से डेटा को पुनर्स्थापित करता है

यह ViewState के कार्यों का अंतिम है। यह सिर्फ उल्लेखित deserialization प्रक्रिया से जोड़ने के लिए आकर्षक है, लेकिन यह इस प्रक्रिया का हिस्सा नहीं है। ASP.NET ViewState डेटा को deserializes, और फिर IT उस डेटा के नियंत्रण को पॉप्युलेट करता है। कई लेख इन प्रक्रियाओं को भ्रमित करते हैं।

System.Web.UI.Control क्लास में (एक बार फिर, वह वर्ग जिससे सभी सर्वर और क्लाइंट नियंत्रण, जिसमें पृष्ठ शामिल हैं, विरासत में मिले हैं), LoadViewState () विधि को परिभाषित किया गया है, जो टाइप ऑब्जेक्ट के एक पैरामीटर को स्वीकार करता है। यह SaveViewState () विधि के विपरीत है जिसकी हमने पहले ही चर्चा की थी। SaveViewState () की तरह, LoadViewState () केवल StateBag ऑब्जेक्ट पर एक ही विधि कहता है। और स्टेटबाग प्राप्त वस्तु से डेटा के साथ कुंजी / मूल्यों के अपने संग्रह को भरता है। यदि आप रुचि रखते हैं, तो परिणामी वस्तु का प्रकार System.Web.UI.Pair है, दो क्षेत्रों के साथ एक बहुत ही सरल वर्ग, पहला और दूसरा। सबसे पहले कीरेलिस्ट ऑफ़ कीज़ है, और दूसरा एरेलिस्ट ऑफ़ वैल्यूज़ है। StateBag बस इन सूचियों के माध्यम से चला जाता है, और हर बार यह निष्पादित करता है। (कुंजी, मूल्य)। यह देखना महत्वपूर्ण है कि लोडव्यूस्टैट () को पास किया गया डेटा केवल वे रिकॉर्ड हैं जो पिछले अनुरोध में गंदे के रूप में चिह्नित किए गए थे। ViewState से रिकॉर्ड लोड करने से पहले ही, StateBag में पहले से ही कुछ हो सकता है, उदाहरण के लिए, LoadViewState () को कॉल करने से पहले डेवलपर द्वारा स्पष्ट रूप से निर्दिष्ट डेटा। अगर LoadViewState () में दिया गया कुछ मान किसी कारण से पहले से ही StateBag में है, तो इसे अधिलेखित कर दिया जाएगा।

यह सब स्वचालित राज्य प्रबंधन का शुद्ध जादू है। जब पृष्ठ पोस्टबैक के दौरान लोड करना शुरू कर देता है (आरंभ से पहले भी), सभी गुणों को उनके प्राकृतिक डिफ़ॉल्ट मान असाइन किए जाते हैं। तब OnInit होता है। इस चरण में, ASP.NET सभी StateBags पर TrackViewState () कॉल करता है। फिर LoadViewState पिछले अनुरोध के बाद deserialized डेटा के साथ कहा जाता है। StateBag इस सभी डेटा के लिए Add (key, value) करता है। खैर, चूंकि ट्रैकिंग तंत्र पहले से ही चल रहा है, प्रत्येक मान को गंदे के रूप में चिह्नित किया गया है, और इसे अगले पोस्टबैक के लिए फिर से सहेजा गया है। शानदार! ओह। अब आप ViewState के काम के विशेषज्ञ हैं।

ViewState का दुरुपयोग
अब जब हम जानते हैं कि ViewState कैसे काम करता है, तो हम अंततः उन समस्याओं को पहचान सकते हैं जो गलत तरीके से उपयोग किए जाने पर उत्पन्न होती हैं। इस भाग में, मैं ऐसे मामलों का वर्णन करूँगा जो दिखाते हैं कि कितने ASP.NET डेवलपर्स ने ViewState के साथ दुर्व्यवहार किया है। लेकिन ये स्पष्ट त्रुटियां नहीं हैं। उनमें से कुछ बारीकियों से संबंधित हैं जो आपको इस पूरे तंत्र को समझने में मदद करेंगे।

दुरुपयोग के मामले

1. एक डिफ़ॉल्ट मान का प्रस्ताव
2. सेविंग स्टैटिक डेटा
3. सस्ते की बचत (इसके बाद "सस्ते" - लगभग।) डेटा
4. क्रमिक रूप से प्रारंभिक बाल नियंत्रण
5. प्रोग्रामेटिक रूप से प्रारंभिक रूप से बनाए गए नियंत्रण

1. एक डिफ़ॉल्ट मूल्य का प्रस्ताव

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

public class JoesControl : WebControl
{
public string Text
{
get { return this .ViewState[ "Text" ] as string ; }
set { this .ViewState[ "Text" ] = value ; }
}

protected override void OnLoad( EventArgs args)
{
if (! this .IsPostback)
{
this .Text = Session[ "SomeSessionKey" ] as string ;
}

base .OnLoad(e);
}
}

* This source code was highlighted with Source Code Highlighter .

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

< abc:JoesControl id ="joe1" runat ="server" Text ="ViewState rocks!" />

* This source code was highlighted with Source Code Highlighter .

जेन का बहुत बुरा दिन होगा। ताकि वह इस पाठ विशेषता में फिट न हो, जो नियंत्रण उसे नहीं मानता है। गरीब जेन। यह किसी अन्य ASP.NET नियंत्रण की तरह इस नियंत्रण का उपयोग करता है, लेकिन यह एक अलग तरह से काम करता है। जो नियंत्रण जेन मूल्य निर्धारित पाठ मूल्य को अधिलेखित कर देगा! इसके अलावा, जब से जो ने OnLoad में अपना कोड लिखा, ViewState में यह मान गंदा के रूप में चिह्नित किया जाएगा। इसलिए जेन ने सीरीज़ेड व्यूस्टेट क्षेत्र में वृद्धि को केवल अपने पृष्ठ पर जो नियंत्रण डालकर किया है! ऐसा लगता है कि जो जेन के लिए बहुत दयालु नहीं है। हो सकता है कि वह उससे किसी बात का बदला ले। खैर, चूंकि हम सभी जानते हैं कि इस दुनिया में कौन से लिंग नियम हैं (शाब्दिक रूप से, "हम सभी जानते हैं कि कौन सा लिंग इस दुनिया पर शासन करता है" - लगभग)।), हम मान सकते हैं।जेन ने अपना कोड ठीक किया। जेन की खुशी के लिए, जो ने अंततः यह लिखा:

public class JoesControl : WebControl
{
public string Text
{
get
{
return this .ViewState[ "Text" ] == null ?
Session[ "SomeSessionKey" ] :
this .ViewState[ "Text" ] as string ;
}
set { this .ViewState[ "Text" ] = value ; }
}
}

* This source code was highlighted with Source Code Highlighter .

देखें कि कितना कोड घटा है। जो भी OnLoad को फिर से परिभाषित करने के लिए नहीं है। चूंकि स्टेटबाग अशक्त हो जाता है, यदि उसमें वह कुंजी पास नहीं होती है, जो यह देखने के लिए देख सकता है कि क्या इसकी संपत्ति पहले से ही केवल शून्य के लिए जाँच कर सौंपी गई है। यदि समानता रखती है, तो वह अपने प्रिय डिफ़ॉल्ट मान को सुरक्षित रूप से वापस कर सकता है। यदि समानता संतुष्ट नहीं है, तो वह खुशी से निर्धारित मूल्य लौटाता है। कहीं आसान नहीं है।और अब, जब जेन इस नियंत्रण का उपयोग करता है, तो उसे न केवल उसका पाठ विशेषता मान मिलेगा, बल्कि उसके पृष्ठ पर ViewState का आकार बिना किसी कारण के नहीं बढ़ेगा। यह काम करता है - बेहतर। प्रदर्शन बेहतर है। कोड कम है। सरासर लाभ!

2. स्थैतिक डेटा की बचत

यहां, स्थैतिक द्वारा, मेरा मतलब है कि डेटा जो कभी नहीं बदलता है, या एक पृष्ठ के जीवन चक्र के भीतर, या यहां तक ​​कि उपयोगकर्ता सत्र में भी नहीं बदलता है। मान लीजिए कि जो, हमारे कल्पना विक-प्रोग्रामर को, कुछ ईकामर्स एप्लिकेशन के प्रत्येक पृष्ठ के शीर्ष पर वर्तमान उपयोगकर्ता का नाम प्रदर्शित करने का काम दिया गया था। यह उपयोगकर्ता को बताने का एक अच्छा तरीका है "एजियस, हम आपको जानते हैं!" यह उपयोगकर्ताओं को व्यक्तित्व की भावना देता है और दिखाता है कि साइट उसी तरह काम कर रही है जैसा कि इसे करना चाहिए। मान लीजिए कि इस ईकामर्स एप्लिकेशन में एक व्यावसायिक तर्क स्तर एपीआई है जो जो को वर्तमान में प्रमाणित उपयोगकर्ता का नाम आसानी से प्राप्त करने की अनुमति देता है: CurrentUser.Name। यहाँ बताया गया है कि जो इस कार्य को पूरा करता है:

(ShoppingCart.aspx)
< asp:Label id ="lblUserName" runat ="server" />


(ShoppingCart.aspx.cs)
protected override void OnLoad(EventArgs args)
{
this.lblUserName.Text = CurrentUser.Name;
base.OnLoad(e);
}

* This source code was highlighted with Source Code Highlighter .

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

< asp:Label id ="lblUserName" runat ="server" EnableViewState ="false" />

* This source code was highlighted with Source Code Highlighter .

समस्या हल हो गई है।लेकिन एक बेहतर उपाय है। लेबल सबसे अधिक उपयोग किए जाने वाले नियंत्रणों में से एक है, शायद केवल पैनल ही इससे अधिक लोकप्रिय है। इस घटना के पैर विजुअल बेसिक प्रोग्रामर के अनुभव से बढ़ते हैं। VB फॉर्म में टेक्स्ट प्रदर्शित करने के लिए, आपको एक लेबल की आवश्यकता है। यह मानना ​​स्वाभाविक है कि ASP.NET WebForms लेबल में एक समान भूमिका होती है, और यदि आपको कुछ पाठ प्रदर्शित करने की आवश्यकता है, तो आपको लेबल का उपयोग करने की आवश्यकता है। तो, ऐसा नहीं है। लेबल एक टैग में अपनी सामग्री लपेटता है। अपने आप से पूछें कि क्या आपको वास्तव में इस टैग की आवश्यकता है। जब तक आप इस पाठ में कोई शैली नहीं लागू करते हैं, तब तक उत्तर सबसे अधिक संभावना है - नहीं! यह आपके लिए काफी पर्याप्त है:

<% = CurrentUser.Name %>

* This source code was highlighted with Source Code Highlighter .

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

< asp:Literal id ="litUserName" runat ="server" EnableViewState ="false" />

* This source code was highlighted with Source Code Highlighter .

और कोई स्पैन टैग नहीं।

3. "सस्ते" डेटा की बचत

इस आइटम में पहले वाला शामिल है। स्थैतिक जानकारी प्राप्त करना बहुत आसान है। लेकिन सभी आसानी से उपलब्ध जानकारी स्थिर नहीं है। कभी-कभी हमारे पास ऐसे डेटा होते हैं जो एप्लिकेशन के संचालन के दौरान बदल सकते हैं, लेकिन उन तक पहुंचना अभी भी सस्ता है। "सस्ते" से मेरा मतलब है कि खोज की महत्वहीन लागत। इस त्रुटि का एक बहुत ही सामान्य रूपांतर अमेरिकी राज्यों की ड्रॉप-डाउन सूची भर रहा है। जब तक आप एक आवेदन नहीं लिखते हैं जिसे आप 7 दिसंबर 1787 को जहाज करने का इरादा रखते हैं ( यहां)), भविष्य की स्थिति में राज्यों की सूची नहीं बदलेगी। हालाँकि, चूंकि सभी प्रोग्रामर सिर्फ हार्डकोड से नफरत करते हैं, आप शायद इन सभी राज्यों को अपने पेज में नहीं लाना चाहते। लेकिन इस स्थिति में कि अचानक कोई भी राज्य एक विद्रोह (सपने, सपने) उठाता है, आप अपना कोड नहीं बदलना चाहते हैं। हमारे पुराने मित्र जो ने फैसला किया कि वह USSTATES डेटाबेस तालिका से इस ड्रॉप-डाउन सूची को पॉप्युलेट करेंगे। साइट पहले से ही डेटाबेस का उपयोग करती है, इसलिए सब कुछ तुच्छ है - एक तालिका जोड़ें और इसके लिए एक प्रश्न लिखें:

< asp:DropdownList id ="lstStates" runat ="server" DataTextField ="StateName" DataValueField ="StateCode" />

* This source code was highlighted with Source Code Highlighter .

protected override void OnLoad( EventArgs args)
{
if (! this .IsPostback)
{
this .lstStates.DataSource = QueryDatabase();
this .lstStates.DataBind();
}
base .OnLoad(e);
}

* This source code was highlighted with Source Code Highlighter .

डेटा के साथ काम करने वाले किसी भी ASP.NET नियंत्रण की तरह, ड्रॉपडाउन अपने रिकॉर्ड की सूची को याद रखने के लिए ViewState का उपयोग करेगा। वर्तमान में ठीक 50 राज्य हैं। न केवल ड्रॉपडाउन में प्रत्येक राज्य के लिए एक ListItem वस्तु है, बल्कि प्रत्येक राज्य और उसके कोड को क्रमांकित और ViewState को लिखा जाएगा। डेटा का एक पूरा गुच्छा लगातार चैनल लोड होने पर हर बार पृष्ठ लोड होता है, खासकर जब यह डायल-अप कनेक्शन की बात आती है। मैं अक्सर सोचता हूं कि मैं अपनी दादी को कैसे समझाऊंगा कि उसका इंटरनेट इतना धीमा है क्योंकि उसका कंप्यूटर सर्वर पर सभी 50 राज्यों को सूचीबद्ध करता है। मुझे नहीं लगता कि वह समझ पाएगी। शायद वह यह समझाने के बारे में निर्धारित करेगी कि उसकी युवावस्था के समय केवल 46 राज्य थे। ऐसा लगता है कि ये 4 अतिरिक्त राज्य बैंडविड्थ लोड कर रहे हैं। धिक्कार है इन दिवंगत राज्यों को!

स्थिर डेटा के साथ, यह समस्या केवल ViewState के नियंत्रण को अक्षम करके हल की जा सकती है। दुर्भाग्य से, यह हमेशा काम नहीं करता है। यह निश्चित रूप से आपके द्वारा काम कर रहे नियंत्रण और आपके द्वारा उपयोग किए जाने वाले कार्यों पर निर्भर करता है। हमारे उदाहरण में, यदि जो केवल EnableViewState = "गलत" को जोड़ता है और यदि ((! ThisPostPostback) शर्त को हटाता है, तो वह सफलतापूर्वक ViewState में अतिरिक्त डेटा से छुटकारा पा लेगा, लेकिन एक और जटिलता का सामना करेगा। ड्रॉपडाउन अब पोस्टबैक के बाद चयनित मूल्य को याद नहीं रखेगा। बंद करो! यह ViewState के बारे में एक और मिथक है। ड्रॉपडाउन के कारण अब इसका चयनित मूल्य याद नहीं रह सकता क्योंकि आपने इसके लिए ViewState को अक्षम नहीं किया है। DropStdon या Textbox जैसे नियंत्रण ViewState अक्षम होने पर भी अपनी वर्तमान स्थिति को याद रख सकते हैं।ड्रॉपडाउन हमारे द्वारा चयनित मूल्य को भूल जाता है, क्योंकि आप इसे ओनलॉड पर हर बार भरते हैं, इसके बाद इसकी वर्तमान स्थिति को बहाल कर दिया है। जब वह नया डेटा प्राप्त करता है तो सबसे पहला काम वह करता है कि पुराने को डिजिटल ट्रैश में भेजा जाए। इसका मतलब यह है कि जब उपयोगकर्ता कैलिफ़ोर्निया का चयन करता है, तो ड्रॉपडाउन दृढ़ता से इसे डिफ़ॉल्ट मान लौटा देगा (सूची का पहला नंबर, यदि आपने कुछ भी नहीं बदला है)। सौभाग्य से, इस समस्या का एक सरल समाधान है - डेटा लोडिंग को OnInit पर स्थानांतरित करना:ड्रॉपडाउन हठपूर्वक इसे अपने डिफ़ॉल्ट मूल्य पर लौटा देगा (यदि आपने कुछ भी नहीं बदला है तो पहली सूची संख्या)। सौभाग्य से, इस समस्या का एक सरल समाधान है - डेटा लोडिंग को OnInit पर स्थानांतरित करना:ड्रॉपडाउन हठपूर्वक इसे अपने डिफ़ॉल्ट मूल्य पर लौटा देगा (यदि आपने कुछ भी नहीं बदला है तो पहली सूची संख्या)। सौभाग्य से, इस समस्या का एक सरल समाधान है - डेटा लोडिंग को OnInit पर स्थानांतरित करना:

< asp:DropdownList id ="lstStates" runat ="server" DataTextField ="StateName" DataValueField ="StateCode" EnableViewState ="false" />

* This source code was highlighted with Source Code Highlighter .

protected override void OnInit( EventArgs args)
{
this .lstStates.DataSource = QueryDatabase();
this .lstStates.DataBind();
base .OnInit(e);
}

* This source code was highlighted with Source Code Highlighter .

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

4. बाल नियंत्रण के सॉफ्टवेयर आरंभीकरण

कठोर वास्तविकता यह है कि आप कुछ भी घोषित रूप से नहीं कर सकते। कभी-कभी मुश्किल तर्क खेलने में आता है। वास्तव में, यही कारण है कि हम सभी काम करते हैं, है ना? समस्या यह है कि ASP.NET ठीक से एक आसान तरीका प्रदान नहीं करता हैबच्चे को नियंत्रित करने के लिए प्रोग्रामेटिकली इनिशियलाइज़ करें। आप ओनलॉड को ओवरराइड कर सकते हैं और वहां कर सकते हैं - लेकिन फिर आप उस डेटा को सेव करते हैं जो व्यूस्टेट में स्टोर नहीं किया जा सकता है। आप उसी उद्देश्य के लिए OnInit को ओवरराइड कर सकते हैं, लेकिन समान समस्या प्राप्त कर सकते हैं। याद रखें कि ASP.NET, OnInit चरण में TrackViewState () को कॉल करता है। यह पूरे नियंत्रण पेड़ के लिए पुनरावर्ती करता है, लेकिन उत्तर प्रदेश! दूसरे शब्दों में, आपका OnInit आपके वंशजों के OnInit के बाद होता है। इसलिए जिस समय आपका OnInit शुरू होता है, बच्चे के नियंत्रण ने पहले ही उनके ViewStates को ट्रैक करना शुरू कर दिया है! जो फार्म पर घोषित लेबल में वर्तमान तिथि और समय प्रदर्शित करना चाहते हैं:

< asp:Label id ="lblDate" runat ="server" />

* This source code was highlighted with Source Code Highlighter .

protected override void OnInit( EventArgs args)
{
this .lblDate.Text = DateTime .Now.ToString( "MM/dd/yyyy HH:mm:ss" );
base .OnInit(e);
}

* This source code was highlighted with Source Code Highlighter .

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

< asp:Label id ="Label1" runat ="server" Text ="<%= DateTime.Now.ToString() %>" />

* This source code was highlighted with Source Code Highlighter .

आप इसे पहले से ही आजमा चुके होंगे। लेकिन ASP.NET आपको इस तथ्य से सीधे टकराएगा कि सर्वर नियंत्रण के गुणों को सेट करने के लिए वाक्यविन्यास "<% =%>" का उपयोग नहीं किया जा सकता है। जो सिंटैक्स "<% #%>" का उपयोग कर सकता है, लेकिन यह दृष्टिकोण उस डेटा बाइंडिंग विधि से अलग नहीं होगा, जिस पर हमने अभी चर्चा की है (प्रत्येक अनुरोध पर व्यूस्टैट को अक्षम करना और डेटा में भरना)। यह बहुत अच्छा होगा यदि हम कोड में संपत्ति का मूल्य निर्धारित कर सकते हैं, लेकिन साथ ही नियंत्रण को अपने सामान्य मोड में काम करना जारी रखने की अनुमति देते हैं। संभवतः कुछ लेबल इस लेबल के साथ काम करेंगे, और हम चाहते हैं कि इसके द्वारा किए गए सभी बदलाव ViewState में सहेजे जाएं, हमेशा की तरह। उदाहरण के लिए, शायद जो पेज पर वर्तमान तिथि के प्रदर्शन को बंद करने का विकल्प उपयोगकर्ताओं को देना चाहता है,और इसके बजाय एक खाली टेम्पलेट दिखाएं:

private void cmdRemoveDate_Click( object sender, EventArgs args)
{
this .lblDate.Text = "--/--/---- --:--:--" ;
}

* This source code was highlighted with Source Code Highlighter .

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

क्या हम वास्तव में की जरूरत है कि घोषणात्मक रूप से एक मूल्य निर्धारित करना है जो स्थिर नहीं है, लेकिन कुछ कार्यों के परिणामस्वरूप प्राप्त किया गया है। यदि यह घोषित रूप से सेट किया गया है, तो लेबल पहले की तरह काम करेगा - प्रारंभिक स्थिति को सहेजा नहीं जाएगा, क्योंकि यह ट्रैकिंग सक्षम होने से पहले सेट किया गया था, और किसी भी परिवर्तन को ViewState में दर्ज किया जाएगा। जैसा कि मैंने कहा, ASP.NET इस कार्य को पूरा करने का एक आसान तरीका प्रदान नहीं करता है। ASP.NET 2.0 डेवलपर्स को $ -type सिंटैक्स की पेशकश की जाती है, जो अभिव्यक्ति बिल्डरों को गतिशील डेटा स्रोतों (जैसे संसाधन, कनेक्शन स्ट्रिंग्स) से घोषित मूल्य निर्धारित करने की अनुमति देता है। लेकिन "बस इस कोड को निष्पादित करें" जैसे भावों का कोई निर्माता नहीं है, इसलिए यह आपको या तो मदद नहीं करेगा (जब तक कि आप मेरे CodeExpressionBuilder का उपयोग न करें!)। ASP.NET 2.0 डेवलपर्स में OnPreInit भी है। चाइल्ड कंट्रोल को इनिशियलाइज़ करने के लिए यह एक बढ़िया जगह है, क्योंकि यह ईवेंट OnInit से पहले होता है और इसलिए किसी भी ViewState ने अभी तक इसके परिवर्तनों को ट्रैक नहीं किया है, लेकिन सभी कंट्रोल पहले से ही निर्मित हैं। एक समस्या - OnPreInit, अन्य घटनाओं के विपरीत, पुनरावर्ती नहीं है। इसलिए यह केवल पेज पर ही उपलब्ध है। तो यह आपकी मदद नहीं करेगा, यदि आप अपना नियंत्रण लिखते हैं। यह बुरा है कि OnPreInit OnInit, OnLoad और OnPreRender की तरह पुनरावर्ती नहीं है, मुझे इस तरह की असंगति का कोई कारण नहीं दिखता है। समस्या का सार यह है कि हम केवल लेबल संपत्ति का मान सेट करना चाहते हैं, इससे पहले कि ViewState अपने राज्य को ट्रैक करना शुरू कर दे। हम पहले से ही जानते हैं कि OnInit पृष्ठ बहुत देर से हैं।या हो सकता है कि हम किसी तरह से OnInit लेबल में ही काम कर सकें? हम कोड में एक ईवेंट हैंडलर को नहीं लटका सकते हैं, क्योंकि यह संभव है कि यह जल्द से जल्द ऑनइनिट हो, और यह देर हो चुकी है। और यह कंस्ट्रक्टर में नहीं किया जा सकता है, क्योंकि अभी तक कोई बाल तत्व नहीं बनाया गया है। दो तरीके हैं:

1. Init घटना के लिए घोषणात्मक रूप से साइन अप करें

< asp:Label id ="Label2" runat ="server" OnInit ="lblDate_Init" />

* This source code was highlighted with Source Code Highlighter .

यह काम करेगा, क्योंकि लेबल की Init घटना शुरू होने से पहले OnInit विशेषता संसाधित होती है, जो हमें ट्रैकिंग सक्षम होने से पहले सभी जोड़तोड़ को पूरा करने का अवसर देती है। हमारे उदाहरण में, हैंडलर केवल टेक्स्ट प्रॉपर्टी को सेट करेगा।

2. अपना नियंत्रण लिखें

public class DateTimeLabel : Label
{
public DateTimeLabel()
{
this .Text = DateTime .Now.ToString( "MM/dd/yyyy HH:mm:ss" );
}
}

* This source code was highlighted with Source Code Highlighter .

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

5. गतिशील रूप से बनाए गए नियंत्रणों का सॉफ्टवेयर आरंभीकरण

यह पिछले पैराग्राफ की तरह ही समस्या है, लेकिन चूंकि आप स्थिति को बेहतर नियंत्रण में हैं, इसलिए इसे हल करना ज्यादा आसान है। मान लीजिए कि जो ने अपना नियंत्रण लिखा, जो गतिशील रूप से किसी बिंदु पर एक लेबल बनाता है:

public class JoesCustomControl : Control
{
protected override void CreateChildControls()
{
Label l = new Label();

this .Controls.Add(l);
l.Text = "Joe's label!" ;
}
}

* This source code was highlighted with Source Code Highlighter .

हममम।और जब गतिशील रूप से बनाए गए नियंत्रण ट्रैकिंग शुरू करते हैं? आप लगभग किसी भी समय गतिशील रूप से पृष्ठ पर नियंत्रण बना और जोड़ सकते हैं, लेकिन ASP.NET में OnInit पर ViewState की ट्रैकिंग शामिल है। क्या हमारे नियंत्रण इस घटना को याद नहीं करेंगे? नहीं, उन्होंने इसे मिस नहीं किया। तथ्य यह है कि Controls.Add () केवल एक संग्रह में एक आइटम नहीं जोड़ रहा है। यह कुछ ज्यादा है। जैसे ही एक गतिशील रूप से निर्मित नियंत्रण तत्व पेड़ में जोड़ा जाता है, जिसकी जड़ पृष्ठ है, ASP.NET इस तत्व और इसके वंश के लिए सभी लापता घटनाओं को आग लगा देता है। कहते हैं कि आपने एक प्री-रेंडर इवेंट में एक नियंत्रण जोड़ा (हालांकि कई कारण हैं कि यह सबसे अच्छा क्यों नहीं है)। इस बिंदु पर, OnInit, LoadViewState, LoadPostBackData और OnLoad इवेंट पहले ही आ चुके हैं। ठीक उसके बादजैसे ही नियंत्रण पेज नियंत्रण के संग्रह में प्रवेश करता है, इन सभी घटनाओं को इसके लिए शुरू किया जाता है।

इसका मतलब है, मेरे मित्र, कि नियंत्रण के लिए ट्रैकिंग आपको पृष्ठ पर जोड़ने के तुरंत बाद सक्षम हो जाएगी। कंस्ट्रक्टर के अलावा, आप OnInit पर नियंत्रण के गुणों को बदल सकते हैं, और यहां बाल तत्व पहले से ही ViewState के परिवर्तनों को ट्रैक करते हैं। जो CreateChildControls () विधि के लिए सब कुछ जोड़ता है, जिसे ASP.NET कॉल करता है जब उसे यह सुनिश्चित करने की आवश्यकता होती है कि बच्चा नियंत्रण मौजूद है (इस पद्धति को कॉल करने का क्षण इस आधार पर भिन्न होता है कि क्या आप INamingContainer को लागू कर रहे हैं, चाहे पोस्ट प्रोसेसिंग वर्तमान में चल रहा है, क्या किसी को EnsureChildControl ()) कहा जाता है। इसे OnPreRender पर भी कॉल किया जा सकता है। लेकिन जब भी इस विधि को कहा जाता है, यह OnInit के बाद या उसके दौरान होगा, और जो को फिर से ViewState गंदा मिलेगा। यहां समाधान प्राथमिक है, लेकिन यह नोटिस करना आसान नहीं है:

public class JoesCustomControl : Control
{
protected override void CreateChildControls()
{
Label l = new Label();
l.Text = "Joe's label!" ;

this .Controls.Add(l);
}
}

* This source code was highlighted with Source Code Highlighter .

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

public class JoesCustomControl : Control
{
protected override void OnInit( EventArgs args)
{
DropDownList states = new DropDownList();
states.DataSource = this .GetUSStatesFromDatabase();
states.DataBind();

this .Controls.Add(states);
}
}

* This source code was highlighted with Source Code Highlighter .

यह ठीक काम करता है। ड्रॉपडाउन ऐसा व्यवहार करेगा मानो राज्य केवल अंतर्निहित सूची आइटम हैं। वे व्यूस्टेट के लिए नहीं लिखे गए हैं, हालांकि इस नियंत्रण के लिए व्यूस्टैट को शामिल किया गया है, जिसका अर्थ है कि आप व्यूस्टैट के आधार पर इसके सभी कार्यों का उपयोग कर सकते हैं, उदाहरण के लिए, ऑनसेलेटेडइंडेक्सचेंजड इवेंट। आप इसे ग्रिड के साथ भी कर सकते हैं, हालांकि यह सब इस बात पर निर्भर करता है कि आप उनका उपयोग कैसे करते हैं (आपको छँटाई, समस्या आदि हो सकती है)

ViewState के साथ काम करते समय सावधान रहें

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