वैरिएबल पहली बार एक वैरिएबल के रूप में एक बार कई बार या स्टोर पढ़ें?

Question

असल में, क्या यह मूल्य को पहले चर पर एक चर में स्टोर करने के लिए बेहतर है, या लगातार मूल्य का उपयोग करने के लिए? कोड बेहतर समझा जाएगा:

TextWriter tw = null; 
if (!File.Exists(ConfigurationManager.AppSettings["LoggingFile"])) 
{ 
    // ... 
    tw = File.CreateText(ConfigurationManager.AppSettings["LoggingFile"]); 
} 

या

TextWriter tw = null; 
string logFile = ConfigurationManager.AppSettings["LoggingFile"].ToString(); 
if (!File.Exists(logFile)) 
{ 
    // ... 
    tw = File.CreateText(logFile); 
} 

Answer 1

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

Answer 2

2 समाधान मेरे लिए बेहतर है क्योंकि:

• शब्दकोश अनुसंधान एक लागत है
• इसे और अधिक पठनीय है

या यह निजी निर्माता है कि भरता है के साथ आप एक सिंगलटन वस्तु हो सकता है एक बार सभी विन्यास डेटा की आवश्यकता है।

Answer 3

दूसरा सबसे अच्छा विकल्प होगा।

इस अगली स्थिति की कल्पना करें। सेटिंग्स को अन्य थ्रेड द्वारा अपडेट किया जाता है और उनमें से कुछ के दौरान, क्योंकि सेटिंग मान लॉक नहीं होता है, दूसरे मान में परिवर्तन होता है।

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

एक और लाभ यह है कि आप मूल्य को दो बार पुनः प्राप्त नहीं कर रहे हैं। आप एक बार प्राप्त करते हैं, और जहां भी आपके कोड को पूरी सेटिंग पढ़ने की आवश्यकता होती है, आप इसका उपयोग करते हैं।

Answer 4

मुझे पूरा यकीन है, दूसरा एक और अधिक पठनीय है। लेकिन यदि आप प्रदर्शन के बारे में बात करते हैं - प्रारंभिक चरणों और प्रोफाइलर के बिना अनुकूलित न करें।

Answer 5

मुझे दूसरों से सहमत होना चाहिए। पठनीयता और डीआरवाई महत्वपूर्ण है और चर की लागत बहुत कम है क्योंकि अक्सर आपके पास ऑब्जेक्ट्स होंगे और वास्तव में यह चीज़ कई बार स्टोर नहीं करेंगे।

विशेष या बड़ी वस्तुओं के साथ अपवाद हो सकते हैं। यदि आप अपने कैश के भीतर नए मान को जानना चाहते हैं तो आपको कैश का मूल्य बदल सकता है और यदि आप चाहते हैं (अधिकतर बार!)! अपने उदाहरण में, सोचें कि क्या हो सकता है जब ConfigManager.AppSettings ["लॉगिंगफाइल"] दो कॉल के बीच बदलता है (एक्सेसर तर्क या थ्रेड या हमेशा डिस्क से फ़ाइल से मूल्य पढ़ने के कारण)।

पुन: प्रारंभ: लगभग 99% आप दूसरी विधि/कैश चाहते हैं!

Answer 6

आईएमओ जो आप कैश करने की कोशिश कर रहे हैं उस पर निर्भर करेगा। App.conig से एक सेटिंग कैशिंग एक जीपीआरएस कनेक्शन पर एक वेब सेवा कॉल के परिणामों को कैशिंग के रूप में लाभकारी (कोड पठनीयता के अलावा) के रूप में लाभकारी नहीं हो सकता है।