ConfigurationManager.AppSettings प्रदर्शन चिंताएं

मैं अपने एप्लिकेशन के app.config सेक्शन में सभी कॉन्फ़िगरेशन सेटिंग्स को स्टोर करने की योजना बना रहा हूं ( ConfigurationManager.AppSettings क्लास का उपयोग करके)। चूंकि उपयोगकर्ता ऐप के यूआई (चेकबॉक्स पर क्लिक करके, रेडियो बटन आदि का चयन करके) सेटिंग्स बदलता है, इसलिए मैं उन परिवर्तनों को AppSettings पर लिखने की योजना बना रहा हूं। साथ ही, जब प्रोग्राम चल रहा है, मैं लगातार एक प्रक्रिया से AppSettings तक पहुंचने की योजना बना रहा हूं जो लगातार डेटा संसाधित करेगा। यूआई के माध्यम से सेटिंग्स में परिवर्तन वास्तविक समय में डेटा प्रोसेसिंग को प्रभावित करने की आवश्यकता है, यही कारण है कि प्रक्रिया लगातार AppSettings तक पहुंच जाएगी।

प्रदर्शन के संबंध में यह एक अच्छा विचार है? .NET ऐप्स लिखते समय कॉन्फ़िगरेशन सेटिंग्स को स्टोर और एक्सेस करने के लिए AppSettings का उपयोग करना "सही तरीका" होना चाहिए, लेकिन मुझे चिंता है कि यह विधि निरंतर लोड के लिए नहीं थी (कम से कम सेटिंग्स लगातार पढ़ा जा रहा है)।

अगर किसी के पास इसका अनुभव है, तो मैं इनपुट की सराहना करता हूं।

Update: I should probably clarify a few points.

यह एक वेब अनुप्रयोग नहीं है, इसलिए एप्लिकेशन को डेटाबेस से कनेक्ट करना कॉन्फ़िगरेशन सेटिंग्स को संग्रहीत करने के लिए बस ओवरकिल हो सकता है। यह एक विंडोज़ फॉर्म एप्लीकेशन है।

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

Update 2: I accepted lomaxx's answer because Properties does indeed look like a good solution, without having to add any additional layers to my application (such as a database). When using Properties, it already does all the caching that others suggested. This means any changes and subsequent reads are all done in memory, making it extremely fast. Properties only writes the changes to disk when you explicitly tell it to. This means I can make changes to the config settings on-the-fly at run time and then only do a final save out to disk when the program exits.

बस यह सत्यापित करने के लिए कि वास्तव में मुझे आवश्यक लोड को संभालने में सक्षम होगा, मैंने अपने लैपटॉप पर कुछ परीक्षण किया था और गुणों का उपयोग करके प्रति सेकंड 750,000 रीड और 7,500 लिखने में सक्षम था। यह अब तक और उससे परे है कि मेरा एप्लिकेशन कभी भी भी आवश्यकता के करीब आ जाएगा कि मैं प्रदर्शन को प्रभावित किए बिना गुणों का उपयोग करने में काफी सुरक्षित महसूस करता हूं।

0
ro fr bn

8 उत्तर

क्या मैं पूछ सकता हूं कि आप डेटाबेस में उपयोगकर्ता की सेटिंग्स क्यों नहीं सहेज रहे हैं?

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

0
जोड़ा

SQLite देखें, यह इस विशेष परिदृश्य के लिए एक अच्छा विकल्प की तरह लगता है।

0
जोड़ा

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

0
जोड़ा

ऐप सेटिंग्स वास्तव में आप जो करने की कोशिश कर रहे हैं उसके लिए नहीं है।

जब आपका .NET एप्लिकेशन प्रारंभ होता है, तो यह app.config फ़ाइल में पढ़ता है, और स्मृति में इसकी सामग्री को कैश करता है। इसी कारण से, आप app.config फ़ाइल पर लिखने के बाद, किसी भी तरह से run.config फ़ाइल को दोबारा पार्स करने के लिए रनटाइम को मजबूर करना होगा ताकि यह सेटिंग्स को फिर से कैश कर सके। यह अनावश्यक है

आपकी कॉन्फ़िगरेशन सेटिंग्स को संग्रहीत करने के लिए सर्वोत्तम दृष्टिकोण डेटाबेस का उपयोग करना होगा।

डेटाबेस के उपयोग को छोड़कर, आप आसानी से बाहरी एक्सएमएल कॉन्फ़िगरेशन फ़ाइल सेट कर सकते हैं। जब आपका एप्लिकेशन शुरू होता है, तो आप इसकी सामग्री को NameValueCollection ऑब्जेक्ट या हैशटेबल ऑब्जेक्ट में कैश कर सकते हैं। जैसे ही आप सेटिंग्स बदलते / जोड़ते हैं, आप इसे उस कैश की गई प्रतिलिपि पर करेंगे। जब आपका एप्लिकेशन बंद हो जाता है, या उचित समय अंतराल पर, आप फ़ाइल में वापस कैश सामग्री लिख सकते हैं।

0
जोड़ा

एक चीज जो मैं कर रहा हूं वह पढ़ने पर एप्सेटिंग को कैश कर रहा है, फिर उस कैश से सेटिंग्स को फ्लश कर रहा है, जिसे ऐप सेटिंग्स को संसाधित करने के लिए सर्वर को वास्तविक भार की मात्रा को कम करना चाहिए।

साथ ही, यदि संभव हो, तो ऐप सेटिंग्स को में तोड़ने को देखें configSections ताकि आप लेखन और कैश से संबंधित सेटिंग्स पढ़ सकें।

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

0
जोड़ा

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

If you're still worried about performance then take a look at SQL Compact Edition which is similar to SQLite but is the Microsoft offering which I've found plays very nicely with winforms and there's even the ability to make it work with Linq

0
जोड़ा

मैं उपयोगकर्ता डेटा संग्रहीत करने के लिए कॉन्फ़िगरेशन फ़ाइलों का उपयोग नहीं करता। एक डीबी का प्रयोग करें।

0
जोड़ा

डायलन,

इस उद्देश्य के लिए एप्लिकेशन कॉन्फ़िगरेशन फ़ाइल का उपयोग न करें, SQL DB (SQLite, MySQL, MSSQL, जो भी हो) का उपयोग करें क्योंकि आपको कॉन्फ़िगरेशन समस्याओं को पढ़ने और लिखने के दौरान समवर्ती मुद्दों के बारे में चिंता करने की आवश्यकता होगी।

आप जिस डेटा को स्टोर करना चाहते हैं उसमें आपके पास बेहतर लचीलापन भी होगा। ऐपसेटिंग अनुभाग केवल एक कुंजी / मूल्य सूची है जिसे आप समय बीतने के साथ आगे बढ़ा सकते हैं और ऐप परिपक्व हो जाता है। आप कस्टम कॉन्फ़िगरेशन अनुभागों का उपयोग कर सकते हैं लेकिन फिर जब आप डिज़ाइन की बात करते हैं तो आप एक नई समस्या क्षेत्र में हैं।

0
जोड़ा