मुझे पता है कि ज्यादातर लोग HttpRuntime का उपयोग करने की सलाह देते हैं। कैश क्योंकि इसमें अधिक लचीलापन है ... आदि। लेकिन यदि आप चाहते हैं कि ऑब्जेक्ट एप्लिकेशन के जीवन के लिए कैश में बने रहें ? चीजों को कैश करने के लिए एप्लिकेशन [] ऑब्जेक्ट का उपयोग करने के लिए कोई बड़ा नकारात्मक पक्ष है?HttpRuntime.Cache [] बनाम आवेदन []
जब तक आप एप्लिकेशन स्थिति का दुरुपयोग नहीं करते हैं, तो मुझे उन वस्तुओं के लिए उपयोग करने में कोई समस्या नहीं दिखाई देती है जिन्हें आप समाप्त नहीं करना चाहते हैं। वैकल्पिक रूप से मैं शायद उस कोड के पास एक स्थिर चर का उपयोग करता हूं जो इसका उपयोग करता है। इस तरह से आप HttpApplicationState से गुज़रने से बचते हैं और फिर सिस्टम के संदर्भ में मजबूर होना पड़ता है अगर मैं अपने डेटा तक पहुंचना चाहता हूं।
लेकिन यह सुनिश्चित करना सुनिश्चित करें कि आप HttpApplicationState में संग्रहीत ऑब्जेक्ट का उपयोग कैसे करते हैं। यदि यह DataSet है जिसे आप प्रत्येक अनुरोध के लिए सामान जोड़ते रहते हैं, तो किसी बिंदु पर आप वेब-सर्वर पर बहुत अधिक मेमोरी खा रहे हैं। यदि आप अनुरोध संसाधित करते हैं तो आप HttpApplicationState पर आइटम जोड़ते रहते हैं, तो कुछ भी हो सकता है, आप किसी भी समय एप्लिकेशन को पुनरारंभ करने के लिए मजबूर करेंगे।
शायद यह आपकी स्थिति में कैश का उपयोग करने का लाभ है। बड़ी मात्रा में स्मृति का उपभोग घातक नहीं है क्योंकि जब आप दुर्लभ हो जाते हैं तो आप ASP.NET को अपने कैश में आइटम जारी करने की अनुमति देते हैं।
जब आप आइटम को स्वचालित रूप से समाप्त करना चाहते हैं या स्मृति दुर्लभ होने पर पुन: दावा प्राप्त करते हैं तो कैश का उपयोग करें। अन्यथा यदि आप कर सकते हैं तो स्थैतिक चर का उपयोग करें, क्योंकि वे बेहतर प्रदर्शन प्रदान करेंगे, फिर अनुप्रयोगस्टेट संग्रह के माध्यम से खोदेंगे। मुझे बिल्कुल यकीन नहीं है कि एप्लीकेशनस्टेट का उपयोग कब किया जाएगा, लेकिन कुछ निश्चित होने के लिए निश्चित हैं।
आवेदन कैश द्वारा बहिष्कृत किया गया है। यदि आपको एप्लिकेशन स्कोप के साथ कुछ चाहिए, तो आपको या तो इसे कक्षा के स्थिर सदस्य के रूप में बनाना चाहिए या कैश का उपयोग करना चाहिए। यदि आप कैश रूट जाना चाहते हैं लेकिन कभी भी इसे समाप्त नहीं करना चाहते हैं, तो आपको कैश में मूल्य डालने पर CacheItemPriority.NotRemovable विकल्प का उपयोग करना चाहिए। ध्यान दें कि इस प्राथमिकता का उपयोग करना संभव है और अभी भी कैश निर्भरताओं का उपयोग करना संभव है, उदाहरण के लिए यदि आपका डेटा फ़ाइल सिस्टम में किसी चीज़ पर निर्भर करता है। सभी CacheItemPriority HttpRuntime को रोकता है। आइटम को समझदारी से साफ़ करने से कैश करें जब यह मेमोरी प्रेशर महसूस करता है और अपने उपयोग को कम करने के लिए अपने कम-हाल ही में उपयोग किए गए एल्गोरिदम का उपयोग करता है जो अधिक उपयोग नहीं देख रहे हैं।
आप क्यों कहते हैं कि आवेदन बहिष्कृत है? मैंने इसे कहीं भी नहीं देखा है और यह दस्तावेज़ीकरण में संकेत नहीं दिया गया है। –
क्योंकि यह सब कुछ कर सकता है, कैश बेहतर कर सकता है। पिछड़ा संगतता को छोड़कर, अब मौजूद होने का कोई कारण नहीं है कि कैश मौजूद है। – ssmith
एप्लिकेशन को कैश पसंद करने का एक और छोटा कारण यह है कि यदि डेटा सभी संवेदनशील है, तो कैश (थोड़ा) अधिक सुरक्षित है। यहां तर्क यह है कि एप्लिकेशन की सामग्री हमेशा डिफ़ॉल्ट रूप से प्रदर्शित होती है जब ASP.NET ट्रेस चालू होता है, या तो पेज स्तर पर या Trace.axd के माध्यम से। चूंकि यह दुर्घटना से हो सकता है, इसलिए आवेदन में संवेदनशील कुछ भी सार्वजनिक रूप से प्रकट होना आसान होगा। ट्रेस आउटपुट में कैश सामग्री प्रदर्शित नहीं होती है। – ssmith