2009-07-23 15 views
15

एएसपी.नेट 3.5 (जहां तक ​​मुझे पता है) में राज्यों का प्रबंधन करने के लिए 6 तकनीकें हैं।उपयुक्त परिस्थितियों में एएसपी.नेट राज्य प्रबंधन

(1) View State 
(2) Cross Page Posting 
(3) Query String 
(4) Session State 
(5) Application State 
(6) Cookies 

क्या कोई मुझे उन परिस्थितियों के कुछ उपयुक्त उदाहरण दे सकता है जहां मुझे इन तकनीकों का उपयोग करना चाहिए?

उदाहरण के लिए:

(*) Session State: Personalization, Buy Cart, etc. 
(*) Cookies: Saving User Credentials, etc. 

उत्तर

5

राज्य प्रबंधन विकल्प

देखें राज्य:

उपयोग जब आप एक पेज है जो अपने आप को वापस पोस्ट करेंगे के लिए जानकारी की थोड़ी मात्रा स्टोर करने के लिए की जरूरत है। व्यूस्टेट संपत्ति का उपयोग बुनियादी सुरक्षा के साथ कार्यक्षमता प्रदान करता है।

नियंत्रण राज्य:

उपयोग सर्वर से दौर यात्राएं जो नियंत्रण के लिए राज्य सूचना की थोड़ी मात्रा स्टोर करने के लिए की जरूरत है।

छिपी हुई फ़ील्ड:

उपयोग जब आप एक पेज है जो अपने आप को या किसी अन्य पृष्ठ पर वापस पोस्ट करेंगे के लिए जानकारी की थोड़ी मात्रा स्टोर करने के लिए की जरूरत है, और जब सुरक्षा नहीं एक मुद्दा है।

आप सर्वर पर सबमिट किए गए पृष्ठों पर केवल एक छिपे हुए फ़ील्ड का उपयोग कर सकते हैं।

कुकीज़:

उपयोग जब आप ग्राहक और सुरक्षा के बारे में जानकारी की थोड़ी मात्रा स्टोर करने के लिए की जरूरत है कोई मुद्दा नहीं है।

क्वेरी स्ट्रिंग:

उपयोग जब आप एक से दूसरे पेज से जानकारी की थोड़ी मात्रा स्थानांतरित कर रहे हैं और सुरक्षा कोई मुद्दा नहीं है।

आप केवल क्वेरी पृष्ठ का उपयोग कर सकते हैं यदि आप एक ही पृष्ठ का अनुरोध कर रहे हैं, या किसी अन्य पृष्ठ को लिंक के माध्यम से।

सर्वर साइड प्रबंधन विकल्प

एप्लीकेशन स्टेट

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

सेशन स्टेट

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

प्रोफ़ाइल गुण

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

डाटाबेस समर्थन

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

+0

http://coscientech.blogspot.com या http://msdn.microsoft.com/en-us/library/z1hkazw7.aspx – xxxxxxxxxadfas

+0

पर जाएं, मैं प्रोफ़ाइल ऑब्जेक्ट और उपयोगकर्ता डेटा व्यवहार में भी आया हूं। मुझे लगता है कि आपको इसे msdn.microsoft.com पर देखना चाहिए – xxxxxxxxxadfas

+0

http://coscientech.blogspot.com/2010/09/aspnet-state-management.html – anonymous

15

वहाँ कारकों है कि इस प्रभावित कर सकते हैं की एक बहुत कुछ है, तो मैं उन सभी को इस पर टिप्पणी नहीं करेंगे। लेकिन यहाँ कुछ संकेत दिए गए हैं:

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

  • Query String - इस स्थिति को संग्रहीत करने के लिए इसका उपयोग करें कि आपको उपयोगकर्ता को पृष्ठ या प्रक्रिया को बुकमार्क करने और बाद में वापस आने की अनुमति देने की आवश्यकता है। फिर भी, आप इसे किसी प्रकार के हैश पर रखना चाहते हैं जिसे आप वास्तव में एक विशाल यूआरएल से बचने के लिए डेटाबेस लुकअप में एक कुंजी के रूप में उपयोग कर सकते हैं (हालांकि हैश की अपनी समस्याएं हैं)। इसके अलावा, बहुत से उपयोगकर्ता सीधे आपकी क्वेरी स्ट्रिंग के साथ झुकाव करना पसंद करते हैं, इसलिए यहां बहुत अधिक डालना खतरनाक हो सकता है। गलती से उन उपयोगकर्ताओं को डेटा का खुलासा करना आसान है जिन्हें इसे इस तरह से नहीं देखा जाना चाहिए।

  • Application State - याद रखें कि यह सभी उपयोगकर्ताओं द्वारा साझा किया जाता है, इसलिए उचित रूप से उपयोग करें। दृश्य गणना जैसी चीजें यहां जा सकती हैं।

  • Cookies - उपयोगकर्ता प्रमाण-पत्रों को संग्रहीत करने के लिए कुकीज़ का उपयोग न करें। वे सिर्फ सादा अनएन्क्रिप्टेड टेक्स्ट फाइलें हैं। सत्र में एक कुंजी स्टोर करने के लिए कुकीज़ का उपयोग करें (यहां तक ​​कि आप यहां कुकी और कम सत्रों का उपयोग कर सकते हैं) और सरल वैयक्तिकरण सेटिंग्स जो उस उपयोगकर्ता और ब्राउज़र के लिए विशिष्ट होंगी। उदाहरण के लिए, काम पर मेरा मॉनिटर आकार घर से अलग है, और इसलिए कुकी में डिस्प्ले आकार/लेआउट सेटिंग्स डालना अच्छा है क्योंकि सेटिंग प्रत्येक कंप्यूटर के लिए चिपक जाती है, लेकिन अगर कोई और पढ़ता है तो यह मेरी सुरक्षा से समझौता नहीं करेगा जानकारी।

अब मैं "क्वेरी स्ट्रिंग" अनुभाग से इस अवधारणा को हाइलाइट करना चाहते हैं:

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

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

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

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

1

यह सुनिश्चित नहीं है कि आपका मतलब कैश एप्लिकेशन राज्य द्वारा ऑब्जेक्ट है।

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

+0

कैश ऑब्जेक्ट डाटाबेस या फ़ाइल सिस्टम से हर बार पढ़ने से रोकने के लिए स्थिर डेटा (या कोई भी डेटा जो अधिक नहीं बदलता है लेकिन आपके ऐप द्वारा संदर्भित किया जाता है) को स्टोर करने के लिए एक शानदार जगह है। अधिक जानकारी के लिए – Keith

1

(3) क्वेरी स्ट्रिंग (4) सत्र स्थिति (5) आवेदन राज्य (6) कुकीज़

1. Viewstate

  • अस्वीकरण: यथासंभव कम प्रयोग करें । अच्छा बिंदु है यदि संभव हो तो प्रत्येक राज्य एक यूआरएल द्वारा पहुंच योग्य है।
    • एफ.ई. पेजिंग पेज-चक्रों के बीच नियंत्रण राज्य बने रहने (Viewstate में पेज भंडारण की तो /url/?p=2 बजाय)
  • उपयोग URL का उपयोग करना चाहिए।
    • एफ.ई. चयनित आइटम को चेकबॉक्स में स्टोर करें, ताकि आप यह निर्धारित कर सकें कि यह बदल गया है या नहीं।

2. क्रॉस पृष्ठ पोस्ट करना

मत करो। व्यूस्टेट के लिए अस्वीकरण देखें। इसके लिए यूआरएल का प्रयोग करें, या डेटा को किसी सत्र/कुकी/प्रोफाइल में स्टोर करें यदि गुणों के भार को चारों ओर रखा जाना चाहिए।

सीपीपी का प्रमुख नकारात्मक पक्ष यह है कि उपयोगकर्ता अपने वेबब्रोसर में 'बैक' और 'फॉरवर्ड' बटन का उपयोग नहीं कर सकता है। जब कोई उपयोगकर्ता बैक बटन पर क्लिक करता है तो वह उस पृष्ठ पर सबकुछ पूर्ववत करना चाहता है और अंतिम बार पुनः प्रयास करना चाहता है। एक विज़ार्ड के माध्यम से क्लिक करने के लिए सीपीपी का उपयोग करते समय; यह व्यवहार बहुत संभव नहीं है 'क्या आप वाकई blablablabl को फिर से भेजना चाहते हैं'।

3।क्वेरी स्ट्रिंग

बहुत उपयोग करें। प्रत्येक दृश्यमान स्थिति जो एक पृष्ठ तक पहुंच सकती है उसे यूआरएल द्वारा सुलभ किया जाना चाहिए। स्क्रीनreaders वाले लोग इसके लिए आपको धन्यवाद देंगे। और क्वेरी स्ट्रिंग का उपयोग करके जावास्क्रिप्ट-केवल समाधानों का उपयोग करने की आवश्यकता नहीं है।

/url/?page=2 // when doing paging, don't use postback for this 
/url/?tab=advanced-search // when having tabs on top of your page 
शॉर्ट रहने वाले वस्तुओं के लिए

आदि

4. सेशन स्टेट

उपयोग इस, कि केवल भावना इस समय आगंतुक आपकी साइट का दौरा कर सकते हैं। उदाहरण के लिए:

  • जो एक निश्चित विज़ार्ड के चरण
  • पेज एक उपयोगकर्ता का दौरा किया था इससे पहले कि
  • छोटी वस्तुओं आप कैश में रखना चाहते हैं पर पहुँच गया था, लेकिन उस उपयोगकर्ता के लिए बाध्य कर रहे हैं

जैसी चीजों के लिए सत्र लेकिन प्रोफाइल का उपयोग न करें:

  • पसंद
  • चयनित भाषा

क्योंकि ये चीजें अगली बार उपयोगकर्ता आपकी साइट पर आने पर भी समझ में आती हैं।

5. एप्लीकेशन स्टेट

कभी। इसके लिए एएसपी.NET कैश, या memcached, या किसी भी कैशिंग ढांचे का उपयोग करें।

6. कुकीज़

सत्र आईडी, प्रमाणीकृत उपयोगकर्ताओं के लिए प्रोफ़ाइल आईडी; अज्ञात उपयोगकर्ताओं के लिए उपयोगकर्ता वरीयताएं (सबकुछ दूसरी सूची में सूचीबद्ध है 4.)।

संबंधित मुद्दे