में डेटा कैश बनाम सत्र ऑब्जेक्ट किसी साइट के लिए गतिशील व्यावसायिक ऑब्जेक्ट्स उपयोगकर्ता सत्र में संग्रहीत किया जाना चाहिए या ASP.Net कैशिंग (ऑब्जेक्ट्स जैसे ऑर्डर, प्रोफाइल जानकारी इत्यादि) का उपयोग करना चाहिए?एएसपी.Net
मैंने उन साइटों के साथ काम किया है जो व्यापार वस्तुओं को स्टोर करने के लिए सत्रों का उपयोग करते थे, लेकिन मैं सोच रहा था ... कैशिंग के फायदे या नुकसान क्या हैं?
यदि ऑब्जेक्ट उपयोगकर्ता सत्रों के बीच साझा करने योग्य हैं, तो कैश का उपयोग करें। यदि ऑब्जेक्ट प्रत्येक सत्र के लिए अद्वितीय होते हैं - शायद इसलिए कि वे अनुमतियों द्वारा शासित होते हैं - फिर इसे सत्र में संग्रहीत करें। इन-प्रोसेस सत्र स्वयं कैश में संग्रहीत होता है, इसलिए निर्णायक कारक वास्तव में डेटा का दायरा होना चाहिए।
एएसपी.नेट सिस्टम कैश एप्लिकेशन के लिए वैश्विक है जहां सत्र वर्तमान उपयोगकर्ता के लिए अद्वितीय है। यदि आपने वस्तुओं को स्टोर करने के लिए वैश्विक कैश का उपयोग करना चुना है तो आपको ऑब्जेक्ट पहचान रणनीति बनाने की आवश्यकता होगी ताकि आप अपने प्रति उपयोगकर्ता आधार के लिए सही ऑब्जेक्ट प्राप्त कर सकें।
यदि आप प्रदर्शन को बढ़ाने की सोच रहे हैं तो आप एएसपी.NET सत्र स्थिति को एक वितरित मेमोरी कैश जैसे माइक्रोसॉफ्ट के वेग के साथ बदलना बेहतर होगा। माइक्रोसॉफ्ट ने Velocity को लक्षित करने के लिए सत्र उपयोग को प्रतिस्थापित करने के तरीके पर आलेख पोस्ट किए हैं। आप संबंधित फैशन में मेमकेचे या अन्य समान उत्पादों का भी उपयोग कर सकते हैं।
सत्र ऑब्जेक्ट उपयोगकर्ता-केवल-डेटा के लिए उपयुक्त हैं, दूसरी ओर, कैश ऑब्जेक्ट्स एप्लिकेशन के लिए साझा किए गए डेटा के लिए अधिक उपयुक्त हैं।
एक या दूसरे में सहेजने की कुंजी यह निर्धारित करना है कि आप स्टोर करने का प्रयास कर रहे हैं या नहीं, केवल उपयोगकर्ता ही डेटा होगा या इसे सभी एप्लिकेशन में साझा करने की आवश्यकता है।
सत्र => एक चरण-दर-चरण इंटरफ़ेस वाला एक वेबपृष्ठ (उदाहरण के लिए एक ऑनलाइन परीक्षण)।
कैश => किसी प्रकार के मौसम विजेट में प्रदर्शित जानकारी (जैसे कि Google के igoogle.com पृष्ठ में है)।
उम्मीद है कि यह मदद करता है।
कैशिंग बस यही है - कैशिंग। आप वहां मौजूद प्रविष्टियों पर कभी भरोसा नहीं कर सकते हैं, इसलिए उस सम्मान में कोई धारणा नहीं की जानी चाहिए: डेटा को रीफ्रेट करने के लिए सीधे डीबी (या कहीं और) पर जाने के लिए तैयार रहें।
दूसरी ओर, सत्र वस्तुओं को संग्रहित करने के लिए अधिक अनुकूल है, हालांकि व्यक्तिगत रूप से मैं डीबी के पक्ष में सत्र स्टोर से बचने की कोशिश करता हूं।
interface ISessionStore
{
T GetEntry<T>(string key);
void SaveEntry<T>(string key, T entry);
}
और फिर "निर्भरता-इंजेक्शन लगाने के" उचित कार्यान्वयन, यह InmemorySessionStore, DbSessionStore या जो कुछ भी हो सकता है: मैं आमतौर पर कि एक अपारदर्शी ISessionStoreService इंटरफ़ेस के पीछे दुकान दूर सार संक्षेप द्वारा करते हैं।
हालांकि आप अपने व्यापार ऑब्जेक्ट को कैश में स्टोर कर सकते हैं, लेकिन कैश को प्रदर्शन सुधार के लिए डिज़ाइन किया गया है जो राज्य प्रबंधन नहीं है। कल्पना कीजिए कि आपके पास डेटाबेस से 1000 रिकॉर्ड प्राप्त करने की प्रक्रिया है (और इसमें लगभग 3 सेकंड लगते हैं) और आपको इसे कुछ मिनटों की आवश्यकता होगी। आप अपनी ऑब्जेक्ट्स को कैश में स्टोर कर सकते हैं और इसकी समाप्ति तिथि, प्राथमिकता और निर्भरता (जैसे एसक्लड पर निर्भरता या फ़ाइल निर्भरता) सेट कर सकते हैं, इसलिए अगले अनुरोधों के लिए आप डेटाबेस से इसे पुनर्प्राप्त करने के बजाय कैश किए गए डेटा का उपयोग कर सकते हैं। आप सत्र में अपनी वस्तु को स्टोर कर सकते हैं लेकिन आप डिफ़ॉल्ट रूप से सत्र के लिए निर्भरता सेट नहीं कर सकते हैं। इसके अलावा कैश का एक अनूठा व्यवहार होता है कि जब सिस्टम को स्मृति की आवश्यकता होती है तो यह प्राथमिकता के आधार पर कैश से वस्तुओं को छोड़ देगा। कैश ऑब्जेक्ट्स वैश्विक हैं और सभी उपयोगकर्ताओं के बीच साझा किए जाते हैं लेकिन सत्र साझा नहीं किया जाता है और यह प्रत्येक उपयोगकर्ता (सत्र) के लिए उपयोग योग्य है।
कैश किए गए डेटा के जीवनकाल के लिए एक और विचार नियंत्रण और ग्रैन्युलरिटी का स्तर होगा। वैश्विक सत्र राज्य समय समाप्ति अवधि के आधार पर सत्र आपको एक स्लाइडिंग समाप्ति रणनीति तक सीमित करता है। कैश का उपयोग सीधे आपको इन पैरामीटर पर अतिरिक्त नियंत्रण देता है। –