2008-10-01 9 views
8

में उपयोग के लिए क्लास लाइब्रेरी में सही ढंग से कैश को कार्यान्वित करना मैं कक्षा पुस्तकालय में कैश को कार्यान्वित कर रहा हूं जिसे मैं एएसपीनेट एप्लिकेशन में उपयोग कर रहा हूं।एएसपीनेट अनुप्रयोग

मैंने अपने कैश ऑब्जेक्ट को कैश को अद्यतन करने के लिए एक स्थिर विधि के साथ एक सिंगलटन पैटर्न के रूप में बनाया है जो वास्तव में डेटा संग्रह के साथ एक सदस्य चर/संपत्ति लोड कर रहा है, मुझे कैश की आवश्यकता है (कुछ लॉकिंग लॉजिक ऑफ कॉर्स)। मैं सोचा कि यह एक अच्छा तरीका था के बाद से मैं सिर्फ

MyCacheObject.Instance.MyDataCollection 

बुला मैं एक नया कैश वस्तु बना रहा हूं कुछ प्रमुख द्वारा विभाजित डेटा की एक बहुत बड़ी राशि स्टोर करने के लिए के आधार पर अपने डेटा तक पहुँच सकते जाने के लिए। मैं जो कह रहा हूं वह है कि मैं एक नया कैश बना रहा हूं लेकिन यह एक ही समय में सभी डेटा लोड नहीं करेगा, बल्कि प्रत्येक कुंजी के लिए संग्रह संग्रहित करेगा।

MyOtherCacheObject.Instance.MyOtherDataCollection(indexkey) 

इस बार कचरा संग्रह के बारे में सवाल उठाया गया था। चूंकि मैं बड़ी मात्रा में डेटा संग्रहीत कर रहा हूं, क्या यह अचानक बर्बाद नहीं होगा अगर यह अचानक हो गया? चूंकि यह सिर्फ एक सिंगलटन पैटर्न है, यह सुनिश्चित करने के लिए कुछ भी नहीं है कि डेटा कैश में रहेगा।

तो मेरा सवाल यह है कि - इस स्थिति को संभालने के लिए कैश को लागू करने के लिए सबसे अच्छा अभ्यास क्या है? मुझे वास्तव में इसके लिए एक जटिल जटिल समाधान पसंद नहीं है, और मुझे पता है कि System.Web में कैशिंग है लेकिन यह थोड़ा 'ऑफ' लगता है क्योंकि यह सिर्फ एक क्लास लाइब्रेरी है, या आप क्या सोचते हैं?

उत्तर

9

मेरी राय में, सबसे अच्छा समाधान निम्नलिखित विशेषताएं होगा:

  • का उपयोग करता है अपने खुद के लेखन से बचने की कोशिश मंच द्वारा प्रदान की उपलब्ध कैशिंग सेवाओं।

  • परतों को सुसंगत रखने के लिए, सिस्टम क्लास को अपनी कक्षा लाइब्रेरी को जोड़े नहीं है।

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

तो, मैं आदेश वर्ग पुस्तकालय अलग कैशिंग कार्यान्वयन, पर्यावरण उस पर चल रहा है के आधार पर उपयोग करने के लिए अनुमति देने के लिए एक आईओसी रणनीति का प्रयोग करेंगे।

public interface ICacheService 
{ 
    AddItem(...); 
} 

आप System.Web के आधार पर एक कार्यान्वयन प्रदान कर सकता है:

public AspNetBasedCacheService : ICacheService 
{ 
    AddItem(...) 
    { 
     // Implementation that uses the HttpContext.Cache object 
    } 
} 

और फिर है कि कार्यान्वयन है सिंगलटन 'के रूप में प्रकाशित'

आप अपने सार कैशिंग अनुबंध के रूप में परिभाषित मान लीजिए। ध्यान दें कि आपके मूल दृष्टिकोण के साथ अंतर यह है कि सिंगलटन पूर्ण 'कैश ऑब्जेक्ट' के बजाय एएसपी.NET कैश सेवा आधारित कार्यान्वयन का संदर्भ है।

public class ChacheServiceProvider 
{ 
    public static IChacheService Instance {get; set;} 

} 

आप या तो (global.asax.cs में), या स्टार्टअप पर आलसी आरंभीकरण प्रदर्शन

और हर डोमेन घटक प्रकाशित कैशिंग सेवा का उपयोग करने में सक्षम हो जाएगा द्वारा chaching कार्यान्वयन प्रारंभ करने के लिए होता है यह जानने के बिना कि यह System.Web पर आधारित है।

// inside your class library: 
IChacheService chache = CacheServiceProvider.Instance; 
cache.AddItem(...); 

मैं मानता हूँ कि यह शायद सबसे सरल समाधान नहीं है, लेकिन मैं कोड decoupling और लचीलेपन का त्याग किए बिना ASP.NET कैश कार्यान्वयन का लाभ लेने के लिए लक्ष्य कर रहा हूँ।

मुझे उम्मीद है कि मैं आपका प्रश्न सही समझ गया हूं।

+0

मुझे पसंद है कि आप क्या प्राप्त कर रहे हैं (भले ही मैं आईओसी से बचने के लिए एक लंबा रास्ता तय करूंगा)। आप कुछ अच्छे विचार ला रहे हैं जिन्हें मैं हालांकि चला सकता हूं। धन्यवाद –

+0

यदि आप सेट किया जाता है तो आप बैकिंग वैरिएबल भी जोड़ सकते हैं और उस चर पर लॉक कर सकते हैं। मेरा आंत महसूस करता है कि यह कुछ थ्रेडिंग मुद्दों को रोक सकता है। –

1

डेटा तब तक कचरा नहीं मिलेगा जब तक कैश अभी भी इसका संदर्भ न रखे।

इसके अलावा, कभी भी सिंगलेटन्स का उपयोग न करें।

+0

लेकिन मुझे डर है कि कैशोबजेक्ट जीसीएड डेटा को कैश नहीं करेगा। –

+1

मेरे कैश को पकड़ने के लिए सिंगलटन का उपयोग करने के बजाय, बेहतर दृष्टिकोण क्या होगा? –

+0

कैश ऑब्जेक्ट कचरा क्यों एकत्र करेगा? जब तक इसका कोई संदर्भ नहीं है, यह –

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