लोग सेटिंग फ़ाइलों का उपयोग करने के बजाय ऐपकॉन्फिग का उपयोग क्यों करते हैं? (.NET)

Question

अक्सर मुझे इस सवाल का जवाब दिखाई देता है: "मुझे अपने .NET ऐप में सेटिंग्स कैसे स्टोर करनी चाहिए?" तब

<configuration> 
    <appSettings> 
    **<add key="ConfigValueName" value="ABC"/>** 
    </appSettings> 
</configuration> 

, उन्हें पसंद तक पहुँचने:

string configValue = Configuration.AppSettings["ConfigValueName"]; 

मैं गौर करेंगे app.config फ़ाइल इसलिए की तरह मैन्युअल app.config (या web.config) के लिए प्रविष्टियां जोड़कर संपादित करने के लिए है "app.config" दृष्टिकोण के रूप में ऊपर उल्लिखित दृष्टिकोण के लिए। बहुत कम शायद मैं लोगों को परियोजना में "सेटिंग्स" फ़ाइल जोड़ने की सलाह देता हूं। मैंने इसे वेब पर और स्टैक ओवरफ्लो पर कई बार देखा है ... मुझे आश्चर्य है कि मुझे कुछ याद आ रहा है ... क्योंकि मुझे यकीन नहीं है कि आप इस विधि का उपयोग "सेटिंग्स" "फाइल। मैं वीएस2005 तक .NET में नहीं आया था इसलिए मेरे पास एक सिद्धांत यह है कि वीएस2003 में चीजें कैसे की गईं और लोगों ने कभी भी स्विच नहीं किया?

की सिफारिश app.config दृष्टिकोण लोगों के उदाहरण:

• Simplest way to have a configuration file in a Windows Forms C# Application
• Best-Practices : how should I store settings in C# (Format/Type)?

मेरे दृष्टिकोण से वहाँ की निम्न लाभ कर रहे हैं "सेटिंग फ़ाइल" दृष्टिकोण:

1. एप्लिकेशन सेटिंग्स (जो सभी उपयोगकर्ताओं के लिए आम हैं) और एक ही इंटरफ़ेस से उपयोगकर्ता सेटिंग्स दोनों के लिए उपयोग किया जा सकता है।
2. दृश्य स्टूडियो में सेटिंग्स डिजाइनर समर्थन का उपयोग करने की क्षमता। कम त्रुटि प्रवण फिर एक XML फ़ाइल को सीधे IMHO संपादित करना।
3. रिफैक्टरिंग - आप किसी विशेष सेटिंग नाम का नाम बदल सकते हैं और यह स्वचालित रूप से आपके कोड में संदर्भ अपडेट कर देगा।
4. संकलन प्रकार की जांच।
5. स्वत: पूर्णता समर्थन।
6. संपत्ति-ग्रिड क्षमताओं। मैंने पाया है कि एक त्वरित विकल्प बनाने के लिए PropertyGrid नियंत्रण एक बहुत ही आसान तरीका है। आप बस propertyGrid1.SelectedObject = Settings1.Default; करते हैं और आप कर चुके हैं।

मामले में आप यकीन है कि मैं क्या "सेटिंग" फ़ाइल दृष्टिकोण से मतलब this post जो कुछ उदाहरण की सिफारिश जहां किसी सेटिंग का उपयोग करके app.confg के बजाय फाइल में से एक है देख नहीं कर रहे हैं।

संपादित करें: कृपया समझें: इस विषय का उद्देश्य यह पता लगाने के लिए है कि लोग सेटिंग फ़ाइल दृष्टिकोण पर ऊपर उल्लिखित app.config दृष्टिकोण का उपयोग क्यों करेंगे। मुझे सेटिंग्स फ़ाइल दृष्टिकोण की सीमाओं का सामना करना पड़ा है और कभी-कभी अपने स्वयं के कस्टम समाधान को रोल करने के लिए मजबूर किया गया है। यह एक पूरी तरह से अलग चर्चा है।

Answer 1

मेरा मानना ​​है कि दोनों के बीच सबसे बड़ा अंतर यह है कि एप्लिकेशन app.config में मानों को नहीं बदल सकता है। उन मानों को रनटाइम पर पढ़ा जाता है और कॉन्फ़िगरेशन फ़ाइल में नए मान लिखने के लिए कोई अंतर्निहित समर्थन नहीं होता है।

सेटिंग्स फ़ाइलों को Save() कमांड का उपयोग करके बदला जा सकता है।

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

जब भी आप एक नया संस्करण जारी करते हैं, तो सेटिंग फ़ाइल को संग्रहीत करने के कारण यह पिछले संस्करण से सेटिंग फ़ाइल का पता नहीं लगाएगा। सेटिंग फ़ाइल को संग्रहीत करने के तरीके को बदलने का कोई तरीका नहीं है।

मैंने इसे एक प्रोजेक्ट में उपयोग किया और इसे अपनी खुद की ऐपसेटिंग क्लास बनाने के लिए और अधिक उपयोगी पाया जो सेटिंग्स के लिए एक्सएमएल फ़ाइल का उपयोग करता है। मेरे पास फ़ाइल के स्वरूप और स्थान पर नियंत्रण है।

Answer 2

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

संपादित करें: प्रश्न पूछने वाले व्यक्ति के साथ चर्चा के रूप में, यह उत्तर गलत है क्योंकि प्रश्न सेटिंग फ़ाइल में सहेजने के दो अलग-अलग तरीकों का जिक्र कर रहा है। जब मैंने अपना जवाब दिया, तो मैं सोच रहा था कि वह दो अलग-अलग फाइलों का जिक्र कर रहा था। एकमात्र अन्य उत्तर के बारे में मैं प्रदान कर सकता हूं कि यह व्यक्तिगत वरीयता का मामला है।

Answer 3

चर्चा के बिना, तो जवाब है:

"क्योंकि यह आसान है।"

Answer 4

दो परिदृश्यों:

• जो सामान्य मानों पर सेट विन्यास सेटिंग्स के साथ भेज दिया है एक ग्राहक अनुप्रयोग। ऐप एक उपयोगकर्ता या सभी उपयोगकर्ताओं के लिए सेटिंग्स को संशोधित करने के लिए एक यूआई प्रदान करता है।

यहां "सेटिंग्स" दृष्टिकोण हाथ जीतता है।

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

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

Answer 5

ऐपसेटिंग या गुणों की तुलना में एक तिहाई, और अधिक, बेहतर तरीका है: custom configuration sections। AppSettings से अधिक लाभ:

1) जोरदार

2 पहुँच

) दोनों स्कीमा और फार्म के लिए निर्मित सत्यापन तंत्र टाइप किया है।

3) पीओसीओ इसे अत्यधिक टेस्ट करने योग्य बनाता है - बस अपनी खुद की टेस्ट कॉन्फ़िगरेशन को नया बनाएं।

4) जादू तारों पर कोई निर्भरता नहीं है। ऐसा नहीं है कि आप आसानी से कक्षा में AppSettings को लपेट नहीं सकते हैं और इस तरह से पहुंच सकते हैं, लेकिन 9 5% डेवलपर्स नहीं करते हैं।

5) एक दर्जन या उससे अधिक सेटिंग्स के बाद कॉन्फ़िगरेशन में एक्सएमएल अधिक समझदार हो जाता है। आईपीएचओ के प्रस्तावों की तुलना में भी ज्यादा समझदार।

6) दृश्य स्टूडियो पर इसे अच्छी तरह से काम करने के लिए कोई निर्भरता नहीं है।

अनुमोदित, मैंने कभी भी गुणों का उपयोग नहीं किया क्योंकि मुझे पहले कस्टम कॉन्फ़िगरेशन अनुभागों पर हाथ मिला।

बीटीडब्ल्यू, यदि आपने इनके बारे में नहीं सुना है, तो आप अभी भी उन्हें हर दिन उपयोग कर रहे हैं - आपको क्या लगता है कि .NET कॉन्फ़िगरेशन फ़ाइलों में मानक कॉन्फ़िगरेशन अनुभाग हैं?

_____CLAIRIFICATION खंड

पहले, इस के थोक AppConfig दृष्टिकोण के प्रति उद्देश्य था, और फिर से पढ़ने मैं स्पष्ट नहीं था। मुझे लगता है कि हम आम तौर पर एक ही तरफ हैं - कॉन्फ़िगरेशन के लिए ढीले नाम-मूल्य बैग से बचें क्योंकि यह बहुत आसानी से टूट जाता है। मुझे यह भी जोड़ना चाहिए कि मैं एक वेब लड़का हूं, इसलिए उपयोगकर्ता सेटिंग्स कुछ ऐसा है जो एप्लिकेशन परत में रहती है, कॉन्फ़िगर में नहीं, मेरे लिए।

1) सच है, दोनों गुण और कस्टम कॉन्फ़िगरेशन अनुभागों ने दृढ़ता से उपयोग किया है। AppSettings नहीं करते हैं। ऐपसेटिंग खराब, प्रॉप्स/सीसी अच्छा है।

2) जब आप कॉन्फ़िगरेशन सेक्शन लोड करते हैं, तो एप्लिकेशन एक कॉन्फ़िगरेशन अपवाद फेंक देगा यदि यह आवश्यक जानकारी या अनुचित जानकारी का खुलासा नहीं करता है। जैसे ही आप app.config या web.config को मक करते हैं। एक और अधिक प्रमाणीकरण आधारभूत संरचना है जिसका मैंने उपयोग नहीं किया है क्योंकि मुझे कड़ी मेहनत और जल्दी या असफल होना पसंद है।

3) पीओसीओ पिछले कुछ सालों से चूकने के मामले में सादा पुराना सी # ऑब्जेक्ट है। किसी भी तरह, क्योंकि कॉन्फ़िगरेशन सेटिंग्स सजावटी हैं और विशेषताओं के माध्यम से घोषित की जाती हैं, इसलिए आपकी कॉन्फ़िगरेशन सेटिंग्स को आसानी से परीक्षण किया जा सकता है क्योंकि आपको बस एक नया MyConfigSection() सेट करने और गुणों को सेट करने की आवश्यकता है, आदि। जैसा कि मैं गुणों को समझता हूं, आपको उसमें सही xml के साथ कॉन्फ़िगरेशन फ़ाइल की आवश्यकता होती है या आप सोल हैं। अन्य लाभ कस्टम कॉन्फ़िगरेशन अनुभाग अन्य सभी स्वच्छ सामग्री के साथ काम करते हैं जो आप पीओसीओ के साथ कर सकते हैं, जैसे इंटरफेस और निर्भरता इंजेक्शन।

4) सच है, गुण और कस्टम कॉन्फ़िगरेशन अनुभाग दोनों दृढ़ता से टाइप किए गए हैं, AppSettings नहीं हैं। ऐपसेटिंग खराब, प्रॉप्स/सीसी अच्छा है।

5) वास्तव में ऐप सेटिंग्स का लक्ष्य रखा गया। मुझे कॉन्फ़िगरेशन में <add name="foo" value="bar" /> के कट्टरपंथी 2 पृष्ठों के साथ कुछ ऐप्स विरासत में मिला है। एक्सएमएल जिबर्बिश की तुलना में यह आसान है कि गुण थूकते हैं। दूसरी ओर, आपका कस्टम कॉन्फ़िगरेशन अनुभाग अपेक्षाकृत अर्थपूर्ण और आत्म-व्याख्यात्मक हो सकता है क्योंकि आप अनुभाग के नाम और विशेषताओं की घोषणा कर रहे हैं। मैं इसे उत्पादन सर्वर पर नोटपैड में आसानी से संपादित कर सकता हूं और पैर में खुद को एक चुटकी में शूट करने के बारे में बहुत परेशान नहीं हो सकता।

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

Answer 6

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

विन XP: c: \ दस्तावेज़ और सेटिंग्स \% प्रयोक्ता नाम% \ Local Settings \ Application Data {प्रकाशक का नाम} \

विन 7: C: \ Users \% प्रयोक्ता नाम% \ AppData \ Local {प्रकाशक का नाम } \

जबकि app.config सेटिंग्स केवल कॉन्फ़िगरेशन फ़ाइल में सहेजी जाती हैं।

Answer 7

क्योंकि सेटिंग्स फ़ाइल आधारभूत संरचना (1) अधिक जटिल है और (2) अपर्याप्त रूप से इसकी जटिलता को दस्तावेज किया गया है।

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

मैं निष्कर्ष निकालने के लिए this आलेख का संदर्भ देता हूं। मेरे तर्क के विरोधाभास के लिए वैचारिक एमएसडीएन दस्तावेज के कुछ उपयोगी लिंक पेस्ट करने के लिए स्वतंत्र महसूस करें।

---

अद्यतन:

मैं उचित हो सकता है और एक विशिष्ट उपयोग के मामले में जो मैं दस्तावेज नहीं मिला देने की आवश्यकता:

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