ASP.NET अनुप्रयोग कैशिंग मॉड्यूल

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


कई घंटों के शोध के बाद, इस समस्या को हल करने के लिए निम्नलिखित तरीके पाए गए:

1) कैश्ड होने के लिए पृष्ठ पर "OutputCache" निर्देश की एक घोषणात्मक घोषणा।

<%@ OutputCache Duration="600" VaryByParam="*" VaryByCustom="custom" %> 

2) "CoudeBehind" पेज में Response.Cache ऑब्जेक्ट के कैशिंग पैरामीटर सेट करना:

  HttpCachePolicy policy = Response.Cache; policy.SetCacheability(HttpCacheability.Server); policy.SetExpires(app.Context.Timestamp.AddSeconds((double)600)); policy.SetMaxAge(new TimeSpan(0, 0, 600)); policy.SetValidUntilExpires(true); policy.SetLastModified(app.Context.Timestamp); policy.VaryByParams.IgnoreParams = true; 

इन दोनों दृष्टिकोणों में महत्वपूर्ण नुकसान हैं, जैसे:

• लचीलेपन की कमी
• प्रत्येक पृष्ठ पर पैरामीटर सेट करने की आवश्यकता

कार्य के मेरे विश्लेषण में जो पहली इच्छा पैदा हुई, वह थी एक सार्वभौमिक कैशिंग मॉड्यूल का निर्माण करना, जो अब हम करेंगे।

सबसे पहले, आपको एक नई परियोजना बनाने की आवश्यकता है। यह हमें अपने मॉड्यूल को एक पुस्तकालय के रूप में लागू करने की अनुमति देगा, जो इसे विभिन्न परियोजनाओं से कनेक्ट करना संभव बना देगा और इसे पूरी तरह से सार्वभौमिक बना देगा।

मॉड्यूल कार्यान्वयन

आइए एक वर्ग "OutputCacheModule" बनाएं जो "IHttpModule" इंटरफ़ेस को लागू करता है, और दो विधियों "निपटान" और "Init" को लागू करता है। हमारे मामले में, "डिस्पोज़" पद्धति को कार्यान्वयन के बिना छोड़ा जा सकता है, और "इनिट" विधि को करीब माना जाता है।
"Init" पद्धति "HttpApplication" को स्वीकार करती है, इससे आप एप्लिकेशन की वैश्विक घटनाओं तक पहुँच प्राप्त कर सकते हैं, जिनका उपयोग आपको हमारे हित की कई घटनाओं की सदस्यता लेते समय करना चाहिए:

 public void Init(HttpApplication app) { app.PreRequestHandlerExecute += new EventHandler(OnApplicationPreRequestHandlerExecute); app.PostRequestHandlerExecute += new EventHandler(OnPostRequestHandlerExecute); } 

"PostRequestHandlerExecute" विधि को तुरंत बुलाया गया पृष्ठ या अन्य हैंडलर अनुरोध को पूरा करने के बाद कहा जाता है। इस स्तर पर, हम कई शर्तों की जाँच करते हैं और कैशिंग की आवश्यकता पर निर्णय लेते हैं और आवश्यक "हेडर" जोड़ते हैं:

 public void OnPostRequestHandlerExecute(object sender, EventArgs e) { HttpApplication app = (HttpApplication)sender; Int32 duration = CacheHelper.GetCacheDuration(app.Context.Request); HttpCachePolicy policy = app.Response.Cache; if (!InverseContext.User.IsAuthenticated && duration > 0) { policy.SetCacheability(HttpCacheability.Server); policy.SetExpires(app.Context.Timestamp.AddSeconds(duration )); policy.SetMaxAge(new TimeSpan(0, 0, duration )); policy.SetValidUntilExpires(true); policy.SetLastModified(app.Context.Timestamp); policy.VaryByParams["*"] = true; } else { policy.SetCacheability(HttpCacheability.NoCache); policy.SetExpires(app.Context.Timestamp.AddSeconds(0)); } } 

यह दृष्टिकोण आपको कैचिंग स्थितियों को लचीले ढंग से प्रबंधित करने और यदि आवश्यक हो तो प्रत्येक व्यक्तिगत पेज के लिए आवश्यक कॉन्फ़िगरेशन को चुनने की अनुमति देता है।

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

  public void OnApplicationPreRequestHandlerExecute(object sender, EventArgs e) { HttpApplication app = (HttpApplication) sender; if (!InverseContext.User.IsAuthenticated) { app.Context.Response.Cache.AddValidationCallback(new HttpCacheValidateHandler(Validate), app); } } 

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

 public void Validate(HttpContext context, Object data, ref HttpValidationStatus status) { if (InverseContext.User.IsAuthenticated) { status = HttpValidationStatus.IgnoreThisRequest; context.Response.Cache.AddValidationCallback(new HttpCacheValidateHandler(Validate), "somecustomdata"); } else { status = HttpValidationStatus.Valid; } } 

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

• IgnoreThisRequest - पृष्ठ फिर से काम करेगा, लेकिन कैश में पड़ा संस्करण मान्य रहेगा।
• अमान्य - पृष्ठ फिर से काम करेगा, कैश में संस्करण को अमान्य के रूप में पहचाना जाएगा और इस अनुरोध में काम किया गया एक नया स्थान दिया जाएगा।
• मान्य - कैश मान्य है, जवाब कैश से पेज का संस्करण होगा।

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

 private void PrintServiceInformation(HttpApplication app) { app.Context.Response.Write("Rendered at " + DateTime.Now + "<br/>"); var cacheability = app.Context.Response.Cache.GetType().GetField("_cacheability", BindingFlags.NonPublic | BindingFlags.Instance).GetValue(app.Context.Response.Cache); app.Context.Response.Write("HttpCacheability = " + cacheability); var expires = app.Context.Response.Cache.GetType().GetField("_utcExpires", BindingFlags.NonPublic | BindingFlags.Instance).GetValue(app.Context.Response.Cache); app.Context.Response.Write("<br/> UtcExpires = " + expires); } 

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

माइक्रोसॉफ्ट का आखिरी सा जादू टोना

1) "Responce.Flush ()" विधि का उपयोग उन स्थानों पर न करें जहां इसे कैशिंग का उपयोग करना है, क्योंकि यह विधि "HttpCacheability.Pirt" पैरामीटर के साथ "HttpCacheability.Pirt" पैरामीटर को कॉल करती है जब साइट IIS सर्वर चला रही है, और इसे पीस लें। असंभव (पैरा 2 देखें)।

2) ASP.Net में कैशिंग मापदंडों को समाप्त नहीं किया जा सकता है, जब "HttpCacheability" विधि की जाँच करने की कोशिश की जा रही है

 if (s_cacheabilityValues[(int)cacheability] < s_cacheabilityValues[(int)_cacheability]) 

और "एनम" इस प्रकार है:

 public enum HttpCacheability { NoCache = 1, Private = 2, Server = 3, ServerAndNoCache = 3, Public = 4, ServerAndPrivate = 5, } 

इसलिए जो पहले से ही खड़ा है, उससे "इंट" मूल्य पर अधिक मूल्य लगाना असंभव है। "SetExpires" विधि इसी तरह काम करती है।