विंडोज रजिस्ट्री सर्वोत्तम प्रथाओं

Question

विंडोज रजिस्ट्री का उपयोग किस तरह से किया जाना है? मुझे पता है कि उपयोगकर्ता प्राथमिकताओं की एक छोटी राशि को स्टोर करना ठीक है, लेकिन क्या यह आपके सभी उपयोगकर्ताओं के डेटा को स्टोर करने के लिए खराब अभ्यास माना जाता है? मुझे लगता है कि यह डेटा सेट पर निर्भर करेगा, तो डेटा की थोड़ी मात्रा के बारे में, कहें, 2KB से कम, 100 या बहुत अलग कुंजी/मूल्य जोड़े में। क्या यह बुरा अभ्यास है? एक फ्लैट फ़ाइल या SQLite डीबी एक बेहतर अभ्यास होगा?

Answer 1

मेरे लिए, सरल उपयोगकर्ता कॉन्फ़िगरेशन आइटम और उपयोगकर्ता डेटा किसी साधारण XML कॉन्फ़िगरेशन फ़ाइल, SQLLite डीबी, या एक एमएस SQL ​​सर्वर कॉम्पैक्ट डीबी में संग्रहीत करने के लिए बेहतर है। सटीक भंडारण माध्यम कार्यान्वयन के विनिर्देशों पर निर्भर करता है।

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

Answer 2

मुझे लगता है कि माइक्रोसॉफ्ट विंडोज रजिस्ट्री के बजाय पृथक भंडारण के उपयोग को प्रोत्साहित कर रहा है।

Here's एक लेख जो बताता है कि इसका उपयोग कैसे करें .Net।

आप उन फ़ाइलों को Windows XP में दस्तावेज़ & सेटिंग्स \\ स्थानीय सेटिंग्स \ ऐप डेटा \ पृथक संग्रहण के अंतर्गत पा सकते हैं। डेटा .dat फ़ाइलों में है

Answer 3

चूंकि प्रत्येक उपयोगकर्ता के पास पहले से ही उपयोगकर्ता डेटा डेटा संग्रहीत करने के लिए समर्पित विंडोज़ में निर्देशिका स्थान है, तो मैं इसे उपयोगकर्ता-स्तरीय डेटा (प्राथमिकता, उदाहरण के लिए) स्टोर करने के लिए उपयोग करता हूं।

सी # में, मैं यह कुछ इस तरह करने से मिलेगा:

Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData); 

आमतौर पर, मैं SQLite फ़ाइलें स्टोर या जो भी आवेदन के लिए उपयुक्त है जाएगा।

Answer 4

डेटा स्टोर करने के लिए रजिस्ट्री का उपयोग मुख्य रूप से एक समस्या है: यह बहुत उपयोगकर्ता के अनुकूल नहीं है। उपयोगकर्ताओं को उनकी सेटिंग्स का बैक अप लेने, उन्हें किसी अन्य कंप्यूटर पर कॉपी करने, उन्हें दूषित होने पर समस्या निवारण (या उन्हें रीसेट करने) का कोई मौका नहीं है, या आमतौर पर केवल देखें कि उनका सॉफ़्टवेयर क्या कर रहा है।

अंगूठे का मेरा नियम केवल ओएस के साथ संवाद करने के लिए रजिस्ट्री का उपयोग करना है। Filetype एसोसिएशन, अनइंस्टॉलर प्रविष्टियां, स्टार्टअप पर चलाने के लिए प्रक्रियाएं, उन चीज़ों को स्पष्ट रूप से रजिस्ट्री में होना चाहिए।

लेकिन आपके एप्लिकेशन में उपयोग के लिए डेटा केवल आपके ऐप डेटा फ़ोल्डर में एक फ़ाइल में है। (3+ ऐप डेटा फ़ोल्डर्स में से एक जो माइक्रोसॉफ्ट वर्तमान में आपको उपयोग करना चाहता है, वैसे भी)

Answer 5

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

पहले की नौकरी में मैंने एक ऐसे व्यक्ति को देखा जो डेटा ट्रांसफर पूर्णता प्रतिशत संग्रहीत करता था, प्रत्येक 10k या उससे भी अधिक समय में नए मान लिखता था और जीयूआई को हर दूसरे मूल्य को इस मूल्य को पुनः प्राप्त करने के लिए यह टाइटलबार पर दिखाया जा सकता था।

Answer 6

मैं अंतर होगा:

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

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

मैं मुख्य रूप से इसे istmatt sais की तरह करता हूं: मैं %APPDATA% फ़ोल्डर के अंदर कॉन्फ़िगरेशन फ़ाइलों को संग्रहीत करता हूं। आम तौर पर %APPDATA%\ApplicationName में, मुझे APPDATA%\CompanyName\ApplicationName\Version के .NET डिफ़ॉल्ट पसंद नहीं है, विस्तार और जटिलता का स्तर अधिकांश छोटे से मध्यम आकार के अनुप्रयोगों के लिए प्रतिकूल है।

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

Answer 7

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

तो रजिस्ट्री को सभी को एक साथ खारिज न करें। यदि कोई मौका है कि कोई व्यवस्थापक नेटवर्क पर आपके कॉन्फ़िगरेशन के कुछ हिस्सों को मानकीकृत करना चाहता है, तो रजिस्ट्री में सेटिंग डालें।

Answer 8

मैं एक विरोधाभासी दृश्य लेने जा रहा हूं।

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

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

एमआरयू सूची के बारे में बात करते हुए इस पोस्ट पर कई अन्य टिप्पणीकारों ने इस समस्या पर चर्चा की है कि एमआरयू सूची आवेदन दुर्घटनाओं के कारण सिंक से बाहर हो जाने पर क्या होता है। मैं सोच रहा हूं कि प्रति उपयोगकर्ता भंडारण में एक फ्लैट फ़ाइल में एमआरयू सूची को संग्रहीत करना बेहतर क्यों है?

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

यदि आप किसी फ़ाइल में अपने उपयोगकर्ता डेटा को स्टोर करने जा रहे हैं, तो आपको कम से कम% APPDATA% \ CompanyName \ ApplicationName में अपना डेटा डालना चाहिए - इस तरह यदि दो अलग-अलग डेवलपर्स एक ही नाम के साथ एक ऐप्लिकेशन बनाते हैं (कितने वहां "मीडिया मैनेजर" एप्लिकेशन हैं?) आपके पास टकराव नहीं होंगे।