कोल्डफ्यूजन - "अनुरोध" दायरे का उपयोग कब करें?

Question

मेरे पूर्ववर्ती के कोड पर जा रहा था और अक्सर "अनुरोध" दायरे का उपयोग देखता था। इस दायरे का उचित उपयोग क्या है?

Answer 1

कई कोड हैं जो आपके कोड के किसी भी हिस्से में उपलब्ध हैं: सत्र, ग्राहक, कुकी, एप्लिकेशन और अनुरोध। कुछ कुछ तरीकों से उपयोग करने के लिए अव्यवस्थित हैं (यानी आपके कस्टम टैग या सीएफसी के अंदर अनुरोध या एप्लिकेशन स्कोप का उपयोग करना; यह coupling है, encapsulation सिद्धांतों का उल्लंघन करता है, और इसे एक बुरा अभ्यास माना जाता है), और कुछ के पास विशेष उद्देश्य हैं: ग्राहक को कुकी पर रखा जाता है मशीन को भौतिक कुकीज़ के रूप में, और सत्र स्कॉप्ड वैरिएबल उपयोगकर्ता-विशिष्ट हैं और वेबसाइट पर उपयोगकर्ता के सत्र के साथ समाप्त हो जाते हैं।

यदि कोई चर बदलने के लिए बेहद असंभव है (सभी उद्देश्यों और उद्देश्यों के लिए निरंतर) और इसे केवल स्टार्टअप स्टार्टअप पर प्रारंभ किया जा सकता है और कभी भी लिखा नहीं जाता है, आम तौर पर आपको इसे एप्लिकेशन स्कोप में रखना चाहिए क्योंकि यह प्रत्येक उपयोगकर्ता और प्रत्येक के बीच रहता है सत्र। जब सही ढंग से कार्यान्वित किया जाता है तो इसे एक बार लिखा जाता है और एन बार पढ़ा जाता है।

Application.cfm में आवेदन चर का एक उचित कार्यान्वयन इस प्रकार दिखाई देंगे:

<cfif not structKeyExists(application, "dsn")> 
    <cflock scope="application" type="exclusive" timeout="30"> 
     <cfif not structKeyExists(application, "dsn")> 
      <cfset application.dsn = "MyDSN" /> 
      <cfset foo = "bar" /> 
      <cfset x = 5 /> 
     </cfif> 
    </cflock> 
</cfif> 

ध्यान दें कि आवेदन दायरे में चर के अस्तित्व से पहले और लॉक के बाद चेक किया जाता है, ताकि दो उपयोगकर्ताओं अगर एप्लिकेशन स्टार्टअप पर रेस हालत बनाएं, उनमें से केवल एक ही एप्लीकेशन वैरिएबल सेट कर देगा।

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

यह एप्लीकेशन.cfc के अतिरिक्त के साथ बहुत सरल था। अब, आप निर्दिष्ट कर सकते हैं जो चर आवेदन स्टार्टअप पर बनाई गई हैं और लॉकिंग और अस्तित्व के लिए जाँच और कि मज़ा सामान के सभी के बारे में चिंता करने की ज़रूरत नहीं है:

<cfcomponent> 
    <cfset this.name = "myApplicationName" /> 

    <cffunction name="onApplicationStart" returnType="boolean" output="false"> 
     <cfset application.dsn = "MyDSN" /> 
     <cfset foo = "bar" /> 
     <cfset x = 5 /> 
     <cfreturn true /> 
    </cffunction> 
</cfcomponent> 

के सभी सहित Application.cfc अधिक जानकारी के लिए उपलब्ध विभिन्न विशेष कार्यों और इसका उपयोग करने के बारे में हर छोटी जानकारी, I recommend this post on Raymond Camden's blog।

संक्षेप में, अनुरोध कोड आपके कोड में हर जगह उपलब्ध है, लेकिन यह हर जगह इसका उपयोग करने के लिए "सही" नहीं है। संभावना है कि आपका पूर्ववर्ती इसका उपयोग encapsulation तोड़ने के लिए कर रहा था, और यह refactor बाहर बोझिल हो सकता है। आप इसे छोड़कर सबसे अच्छा हो सकते हैं, लेकिन यह समझना कि कौन सा गुंजाइश नौकरी के लिए सबसे अच्छा उपकरण है, निश्चित रूप से आपके भविष्य के कोड को बेहतर बना देगा।

Answer 2

यह एक बहुत ही व्यक्तिपरक प्रश्न है, और कुछ यह भी तर्क देंगे कि यह आधुनिक कोल्डफ्यूजन अनुप्रयोगों में अनुरोध दायरे का उपयोग करने के लिए कभी भी "उपयुक्त" नहीं है।

उस अस्वीकरण के रास्ते से, आइए परिभाषित करें कि अनुरोध का दायरा क्या है और यह उपयोगी होगा।

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

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

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

Answer 3

ठीक है, मैं बस आपके कोड पर टिप्पणी करना चाहता था। अगर मैं पागल लग रहा हूं तो कृपया मुझे माफ़ कर दो। लेकिन आप पहले ही सत्यापित कर चुके हैं कि शुरुआत में structKeyExists। चूंकि आप जानते हैं कि यह सच होने जा रहा है, इसलिए यह एक और जांच चलाने के लिए समझ में नहीं आता है। तो इसका मेरा संस्करण यह होगा ... लेकिन यह सिर्फ मुझे है।

---

<cfif not structKeyExists(application, "dsn")> 
    <cflock scope="application" type="exclusive" timeout="30"> 
      <cfset application.dsn = "MyDSN" /> 
      <cfset foo = "bar" /> 
      <cfset x = 5 /> 
    </cflock> 
</cfif> 

---

ठीक है।

Answer 4

मैं अपनी कंपनी की रूपरेखा है कि हमारी साइट शक्ति का उपयोग किया जाएगा लिख ​​रहा हूँ।

मैं कुछ डेटा सेट करने के लिए अनुरोध चर का उपयोग करता हूं जो कि अन्य सीएफसी के लिए उपलब्ध होगा, इसलिए मुझे डेटा में निरंतर पास होने की आवश्यकता के बिना पूरे एप्लिकेशन में उपलब्ध होगा। मैं ईमानदारी से मानता हूं कि अनुरोध का उपयोग करके, और जब तक यह एक स्थिर कार्य घटक के रूप में तब तक आपको कोई समस्या नहीं होनी चाहिए। मुझे यकीन नहीं है कि क्या मैं इसके साथ अपनी सोच में गलत हूं लेकिन एक बार जब मैं ढांचा जारी करता हूं तो हम देखेंगे।