एकाधिक कॉन्फ़िगरेशन फ़ाइल उदाहरणों को संभालने का सबसे अच्छा तरीका?

Question

हम सी # .NET 3.5 में लिखी एक जटिल प्रणाली चलाते हैं, जिसमें 20+ वेबसाइटें, 10+ विंडोज सेवाएं और विभिन्न अनुसूचित कार्य और सहायक ऐप्स शामिल हैं।

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

हम अपने डीएलएल को विभिन्न कारणों से जीएसी में पंजीकृत नहीं करते हैं: 1) हम पूरी प्रणाली के पुनर्निर्माण किए बिना या अनावश्यक डाउनटाइम के बिना चुनिंदा परियोजनाओं में तेजी से रोलिंग की लचीलापन पसंद करते हैं। 2) डीएलएल के कुछ उदाहरणों को थोड़ा अलग विन्यास की आवश्यकता होती है; उदाहरण के लिए कुछ परियोजनाएं विभिन्न कनेक्शन स्ट्रिंग्स, अधिसूचना ई-मेल पते आदि का उपयोग करती हैं।

हमने Web.config/App.config में AppSettings फ़ाइल/configSource विशेषताओं के साथ प्रयोग किया, लेकिन वे केवल परियोजनाओं में नहीं बल्कि सापेक्ष पथों के साथ काम करते हैं। हमने मशीन.कॉन्फिग में डिफ़ॉल्ट को सहेजने पर विचार किया लेकिन यह एक मिशन है, जो बहुत ही अव्यवस्थित है और हमारी परियोजनाओं से संबंधित महत्वपूर्ण सामग्री से भरा है।

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

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

क्या इस समस्या को हल करने का कोई सुझाव, उद्योग-मानक तरीका .NET में है?

Answer 1

यदि यह सब एक ही कंपनी के भीतर है तो आप डेटाबेस में कॉन्फ़िगरेशन क्यों नहीं स्टोर करते हैं? मेरा मानना ​​है कि एंटरप्राइज़ फ्रेमवर्क में एडाप्टर भी हैं जो आप इसे करने के लिए प्लग इन कर सकते हैं।

मुझे हमारी कंपनी में पता है क्योंकि हमारे पास वेबफर्म में चल रही साइटें थीं, हम डीबी में कॉन्फ़िगरेशन स्टोर करेंगे, फिर अगर हमें कुछ बदलने की ज़रूरत है तो हमारे पास एक डीबी स्क्रिप्ट कॉन्फ़िगरेशन अपडेट होगा। साइटों पर धक्का देने की कोई ज़रूरत नहीं है, बस पुनः लोड करने के लिए साइट को पुनरारंभ करना होगा या web.config को स्पर्श करना होगा।

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

तो मुझे लगता है कि मैं क्या कह रहा हूं कि यदि वे सभी एक ही कंपनी/प्रभाव के क्षेत्र में हैं, तो आप उन डेटाबेस का उपयोग कर सकते हैं जो उनके लिए केंद्रीय हैं, बस डीबी का उपयोग करें।

रजिस्ट्री को विनियमित न करें।

Answer 2

मैं OpenExeConfiguration (http://msdn.microsoft.com/en-us/library/ms224437.aspx) का उपयोग करता हूं और प्रत्येक ऐप/डीएलएल 2 कॉन्फ़िगरेशन खोलता है, पहला डिफ़ॉल्ट होगा, दूसरा ओवरराइड होगा।

आप उस "केंद्रीय" स्थान पर डिफ़ॉल्ट रख सकते हैं, जिससे आपके सभी ऐप्स को पढ़ने की पहुंच मिलती है, और स्थानीय ऐप्स आपके ऐप्स के पास रहते हैं।

Answer 3

आपने इन वेब साइटों और अनुप्रयोगों को कैसे तैनात किया था, क्या ये सिस्टम आपके सिस्टम में एक ही मशीन में चल रहे थे, और ये मॉड्यूल एक विशिष्ट निर्देशिका से डीएलएल का आह्वान कर रहे थे?

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

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