2008-08-07 23 views
20

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

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

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

अद्यतन: मुझे शायद कुछ बिंदुओं को स्पष्ट करना चाहिए।

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

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

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

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

उत्तर

8

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

में एक बहुत अच्छी शुरूआत है आप अभी भी प्रदर्शन के बारे में चिंतित हैं तो SQL Compact Edition पर एक नज़र जो SQLite के समान है लेकिन माइक्रोसॉफ्ट की पेशकश है जो मैं WinForms के साथ बहुत अच्छी तरह से खेलता है मिल गया है है और वहाँ भी है ले make it work with Linq

1

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

0

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

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

0

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

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

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

2

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

1

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

2

डायलन करने की क्षमता,

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

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

2

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

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

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

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

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

  • कोई संबंधित समस्या नहीं^_^