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

Question

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

पेशेवरों और उन्हें एक स्थानीय INI फ़ाइल या कॉन्फ़िग फ़ाइल या इसी तरह का भंडारण बनाम Windows रजिस्ट्री में सेटिंग्स को संग्रहीत करने का विपक्ष क्या हैं? कॉन्फ़िग फ़ाइल का

Answer 1

सकारात्मक:

1. आसान करने के लिए। किसी भी विंडोज एपीआई कॉल जानने की जरूरत नहीं है। आपको बस अपनी प्रोग्रामिंग भाषा के फ़ाइल I/O इंटरफ़ेस को जानना होगा।
2. पोर्टेबल। यदि आप अपने एप्लिकेशन को किसी अन्य ओएस पर पोर्ट करते हैं, तो आपको अपने सेटिंग्स प्रारूप को बदलने की आवश्यकता नहीं है।
3. उपयोगकर्ता-संपादन योग्य। उपयोगकर्ता प्रोग्राम निष्पादन के बाहर कॉन्फ़िगरेशन फ़ाइल को संपादित कर सकता है। रजिस्ट्री की

सकारात्मक:

1. सुरक्षित। उपयोगकर्ता गलती से कॉन्फ़िगरेशन फ़ाइल को हटा नहीं सकता है या डेटा को दूषित नहीं कर सकता है जब तक वह regedit के बारे में जानता है। और फिर उपयोगकर्ता सिर्फ परेशानी के लिए पूछ रहा है।
2. मैं कोई विशेषज्ञ विंडोज प्रोग्रामर हूँ, लेकिन मुझे यकीन है कि रजिस्ट्री का उपयोग कर यह आसान अन्य Windows-विशिष्ट बातें (उपयोगकर्ता-विशिष्ट सेटिंग्स, समूह नीति, या जो कुछ भी की तरह नेटवर्क प्रशासन सामान) करने के लिए करता है कि कर रहा हूँ।

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

Answer 2

GetPrivateProfileString के लिए दस्तावेज़ के अनुसार, आप initialisation जानकारी संग्रहीत करने के लिए रजिस्ट्री का उपयोग करना चाहिए।

हालांकि, ऐसा कह, तब भी आप .ini फ़ाइलों का उपयोग करने के लिए, और उन्हें पहुँचने के लिए मानक प्रोफ़ाइल API (GetPrivateProfileString, WritePrivateProfileString, और की तरह) का उपयोग करना चाहते हैं, वे उपलब्ध कराने में निर्मित तरीके स्वचालित रूप से "आभासी प्रदान करने के लिए .ini फाइलें "रजिस्ट्री द्वारा समर्थित। विन-विन!

Answer 3

वहाँ एक समान प्रश्न here कि पक्ष-विपक्ष के कुछ शामिल किया गया है।

मैं रजिस्ट्री का उपयोग नहीं जब तक कि आपके आवेदन पूरी तरह से इसकी आवश्यकता है सुझाव है। मेरी समझ से, माइक्रोसॉफ्ट सेटिंग्स फ़ाइलों की लचीलापन के कारण रजिस्ट्री के उपयोग को हतोत्साहित करने की कोशिश कर रहा है। साथ ही, मैं .ini फ़ाइलों का उपयोग करने की अनुशंसा नहीं करता, बल्कि उपयोगकर्ता/ऐप सेटिंग्स को सहेजने के लिए built-in functionality में से कुछ का उपयोग कर .NET में उपयोग करता हूं।

Answer 4

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

मैं आमतौर पर इस तरह पार्स में अगर प्रारूप करते हैं (।

static void Parse() 
{ 
    StreamReader tr = new StreamReader("config.ini"); 
    string line; 
    Dictionary<string, string> config = new Dictionary<string, string>(); 

    while ((line = tr.ReadLine()) != null) 
    { 
     // Allow for comments and empty lines. 
     if (line == "" || line.StartsWith("#")) 
      continue; 

     string[] kvPair = line.Split('='); 

     // Format must be option = value. 
     if (kvPair.Length != 2) 
      continue; 

     // If the option already exists, it's overwritten. 
     config[kvPair[0].Trim()] = kvPair[1].Trim(); 
    } 
} 

संपादित करें:: INI फ़ाइल विकल्प = मूल्य, प्रति पंक्ति 1, # के साथ शुरू की टिप्पणियां) है क्षमा करें, मैंने सोचा कि आप भाषा का उल्लेख किया था। उपरोक्त कार्यान्वयन सी # में है।

Answer 5

क्या आपका एप्लिकेशन एक सेटअप प्रोग्राम के साथ स्थापित है, या यह सिर्फ "निकालें और चलाएं" है? पहले मामले में, यहां उल्लिखित पेशेवरों और विपक्ष को देखें। लेकिन निकालने और चलाने के लिए, रजिस्ट्री मेरी राय में "नो-गो" है, क्योंकि लोग आपके प्रोग्राम से छुटकारा पाने के लिए एप्लिकेशन फ़ोल्डर को हटाने में सक्षम होने की उम्मीद करते हैं।

Answer 6

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

Answer 7

रजिस्ट्री पर आईएनआई फ़ाइल का उपयोग करने के लिए एक और फायदा है जिसका मैंने उल्लेख नहीं किया है: यदि उपयोगकर्ता किसी प्रकार की वॉल्यूम/फ़ाइल आधारित एन्क्रिप्शन का उपयोग कर रहा है, तो वे आईएनआई फ़ाइल को आसानी से एन्क्रिप्ट किया जा सकता है । रजिस्ट्री के साथ यह शायद अधिक समस्याग्रस्त हो जाएगा।

Answer 8

जेफ एटवुड के पास विंडोज़ रजिस्ट्री के बारे में article है और इसके बजाय .INI फ़ाइलों का उपयोग करना बेहतर क्यों है।

यदि मेरी साइट आसानी से उन्हें देख सकती है, उन्हें कुशल बना सकती है, और उन्हें वापस ले सकती है तो मेरी जिंदगी बहुत आसान हो जाएगी। जैसे, आईएनआई फाइलों में ... कहो।

• रजिस्ट्री विफलता के एकल बिंदु है। यही कारण है कि आप कभी भी पाएंगे कि प्रत्येक रजिस्ट्री संपादन टिप एक बड़ी वसा चिल्लाती अस्वीकरण के साथ शुरू होती है कि आप अपने कंप्यूटर को regedit के साथ कैसे तोड़ सकते हैं।
• रजिस्ट्री अपारदर्शी और बाइनरी है। जितना मैं कोण ब्रैकेट कर को नापसंद करता हूं, कम से कम एक्सएमएल कॉन्फ़िगरेशन फाइलें उचित रूप से मानव-पठनीय हैं, और वे फिट होने पर कई टिप्पणियों की अनुमति देते हैं।
• रजिस्ट्री फाइल सिस्टम के साथ सिंक में होना चाहिए। इसे "अनइंस्टॉल करने" के बिना एप्लिकेशन हटाएं और आपको स्टेल रजिस्ट्री क्रुफ़्ट के साथ छोड़ दिया गया है। या यदि किसी ऐप में खराब लिखित अनइंस्टॉलर है। फाइल सिस्टम अब रिकॉर्ड का बयान नहीं है - इसे किसी भी तरह रजिस्ट्री के साथ सिंक में रखा जाना है। यह DRY सिद्धांत का कुल उल्लंघन है।
• रजिस्ट्री मोनोलिथिक है। आइए मान लें कि आप किसी एप्लिकेशन को अपनी मशीन पर एक अलग पथ पर ले जाना चाहते हैं, या यहां तक ​​कि एक अलग मशीन पर भी। विशाल रजिस्ट्री टैरबॉल से उस विशेष एप्लिकेशन के लिए प्रासंगिक सेटिंग्स निकालने की शुभकामनाएँ। एक दिए गए एप्लिकेशन में आम तौर पर रजिस्ट्री के सभी दर्जनों सेटिंग्स हैं।

Answer 9

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

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

उसने कहा, मैं आईएनआई फ़ाइल की अपील देख सकता हूं, और मैं इसे किसी पर विचार करने के लिए दोष नहीं दूंगा।

Answer 10

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

Answer 11

आईएनआई या कॉन्फ़िगरेशन फ़ाइलों में एक कमी है और यदि उपयोगकर्ता के पास यह चुनने का विकल्प है कि प्रोग्राम कहां स्थापित है, तो उसे ढूंढने का विकल्प है।

Answer 12

मौजूदा उत्तरों में बहुत सारी जमीन शामिल है लेकिन मैंने सोचा कि मैं एक और बिंदु का उल्लेख करूंगा।

मैं सिस्टम-व्यापी सेटिंग्स को संग्रहीत करने के लिए रजिस्ट्री का उपयोग करता हूं। यही है, जब 2 या अधिक कार्यक्रमों को सटीक सेटिंग की आवश्यकता होती है। दूसरे शब्दों में, कई कार्यक्रमों द्वारा साझा की गई सेटिंग।

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

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

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

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

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