Antipattern settings.py

हैबरपिटोनर्स को नमस्कार!

समय-समय पर मेरे पास विकास के पैटर्न आते हैं जो मौजूद नहीं हैं क्योंकि वे एक समस्या को अच्छी तरह से हल करते हैं, लेकिन क्योंकि यह लोकप्रिय एक्स फ्रेमवर्क में किया जाता है, इसलिए, कई लोग सोचते हैं कि यह अच्छा है।

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

तो मेरे विचार में ऐसा दृष्टिकोण घृणित क्यों है।

कैस्केडिंग मुद्दों

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

उदाहरण के लिए, आप MongoDB को संग्रहण के रूप में उपयोग करते हैं। सामान्य तौर पर, आपको इसे लोकलहोस्ट पर my_project करना होगा और my_project नामक DB का उपयोग my_project । हालांकि, यूनिटेस्ट को चलाने के लिए, आपको एक अलग नाम के साथ एक डीबी लेने की जरूरत है ताकि लड़ाकू डेटा को नुकसान न unittests : आइए कहते हैं कि unittests । और उत्पादन के मामले में, आपको लोकलहोस्ट से नहीं, बल्कि मूंगू के तहत दिए गए सर्वर से एक बहुत विशिष्ट आईपी से कनेक्ट करना होगा।

तो बाहरी स्थितियों, settings.MONGODB_ADDRESS पर निर्भर करता है कि कैसे। settings.MONGODB_ADDRESS से एमओंगोडब_एडीडीआरएस अलग-अलग मान लेना चाहिए? आमतौर पर, एक वूडू कंस्ट्रक्शन का उपयोग अंत में किया जाता है, जिसमें __import__ , __dict__ , vars() , try/except ImportError , जो किसी अन्य मॉड्यूल की सेटिंग के साथ नेमस्पेस को पूरक और ओवरलैप करने का प्रयास करता है, जैसे settings_local.py।

अतिरिक्त रूप से लोड किए जाने की आवश्यकता क्या है _local.py हार्डकोड द्वारा या पर्यावरण चर के माध्यम से सेट किया गया है। किसी भी स्थिति में, केवल लॉन्च के समय अपनी सेटिंग्स को चालू करने के लिए समान यूनिटीस्ट के लिए, आपको एक झंझरी के साथ नृत्य करना होगा और ज़ेन ऑफ पायथन का उल्लंघन करना होगा: स्पष्ट रूप से निहित से बेहतर है।

इसके अलावा, इस तरह के एक समाधान एक और समस्या से जुड़ा हुआ है, नीचे वर्णित है।

निष्पादन योग्य कोड

निष्पादन योग्य पाई-कोड के रूप में भंडारण सेटिंग्स डरावना है। वास्तव में, पूरे पैटर्न, जाहिरा तौर पर, शुरू में माना जाता है कि यह एक सरल और सुरुचिपूर्ण समाधान है: “हमें कुछ प्रकार के सीएफजी पार्सर्स की आवश्यकता क्यों है यदि आप अजगर पर सब कुछ ठीक कर सकते हैं? और अधिक अवसर हैं! " परिदृश्य में मामूली से अधिक जटिल, समाधान बग़ल में बदल जाता है। उदाहरण के लिए, ऐसे स्निपेट पर विचार करें:

 # settings.py BASE_PATH = os.path.dirname(__file__) PROJECT_HOSTNAME = 'localhost' SOME_JOB_COMMAND = '%s/bin/do_job.py -H %s' % (BASE_PATH, PROJECT_HOSTNAME) # settings_production.py PROJECT_HOSTNAME = 'my-project.ru' 

क्या आप समझते हैं कि समस्या क्या है? हमने SOME_JOB_COMMAND के कुल मूल्य के लिए ड्रम पर PROJECT_HOSTNAME मान बिल्कुल अवरुद्ध कर दिया। हम ओवरलैप के बाद SOME_JOB_COMMAND की परिभाषा को कॉपी-पेस्ट करने के लिए अपने दाँत SOME_JOB_COMMAND हैं, लेकिन यह भी संभव नहीं है: BASE_PATH फिर, एक अन्य मॉड्यूल में। इसे भी कॉपी-पेस्ट करें? क्या यह बहुत ज्यादा है?

मैं इस तथ्य के बारे में बात नहीं कर रहा हूं कि कॉन्फ़िगरेशन के रूप में निष्पादन योग्य कोड बस कठिन-से- ImportError को जन्म दे सकता है जब एक नए वातावरण में आवेदन शुरू होता है।

इसलिए, मुझे यकीन है कि मक्खियों को अलग-अलग होना चाहिए, कटलेट को अलग से: पाठ फ़ाइल में मूल मान, पी-मॉड्यूल में गणना की जाती है।

उच्च युग्मन

एक अच्छी परियोजना वह है जिसे छोटे क्यूब्स में तोड़ा जा सकता है, और प्रत्येक क्यूब को एक पूर्ण-ओपन ओपन-सोर्स प्रोजेक्ट के रूप में जीथब पर रखा जा सकता है।

जब सब कुछ ऐसा होता है, लेकिन एक BUT के साथ: "कृपया प्रोजेक्ट की जड़ में FOO_BAZ और FOO_QUX सेटिंग FOO_BAR , FOO_BAZ और FOO_QUX " यह किसी भी तरह हास्यास्पद लगता है, है ना? और जब कुछ हास्यास्पद लगता है, तो आमतौर पर इसका मतलब है कि ऐसी परिस्थितियां हैं जिनमें यह बेतुकापन आता है।

हमारे मामले में, उदाहरण लंबे समय तक खुद को आविष्कार नहीं करता है। हमारे एप्लिकेशन को VKontakte API के साथ काम करने दें, और हमारे पास VKontakteProfileCache जैसा कुछ है, जो settings.VK_API_KEY का उपयोग करता है। VKontakteProfileCache और settings.VK_API_SECRET । माथे में VK_API_SECRET। खैर, वह इसका उपयोग करता है और इसका उपयोग करता है, और फिर फिर से, और हमारी परियोजना को कई VKontakte अनुप्रयोगों के साथ तुरंत काम करना शुरू करना चाहिए। और यह वह है, VKontakteProfileCache डिज़ाइन किया गया है ताकि यह केवल एक जोड़ी क्रेडेंशियल्स के साथ काम करे।

इसलिए, सेटिंग्स मॉड्यूल को सीधे एक्सेस न करने के लिए यह अधिक सामंजस्यपूर्ण और अधिक समीचीन है। सभी उपभोक्ताओं को कंस्ट्रक्टर मापदंडों के माध्यम से आवश्यक सेटिंग्स स्वीकार करने दें, निर्भरता इंजेक्शन फ्रेमवर्क के माध्यम से, जैसा कि आप चाहते हैं, लेकिन सीधे नहीं। और कोड की तरह सबसे निम्नतम स्तर दें if __name__ == '__main__' विशिष्ट सेटिंग्स को बाहर निकालता है। और वह उन्हें कहां से मिला - उनकी व्यक्तिगत समस्याएं। इस दृष्टिकोण के साथ, यूनिट परीक्षण को भी बहुत सरल बनाया गया है: आपको किन सेटिंग्स को चलाने की आवश्यकता है, जिनके साथ हम बनाते हैं।

संभव समाधान

इसलिए, "settings.py" पैटर्न मैंने कीचड़ डाला। मैं बेहतर महसूस करता हूं, धन्यवाद। अब एक संभावित समाधान के बारे में। मैंने कई परियोजनाओं में एक समान दृष्टिकोण का उपयोग किया और इसे सुविधाजनक और सूचीबद्ध समस्याओं से रहित पाया।

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

परियोजना में, हम सभी संभव सेटिंग्स और एक उचित डिफ़ॉल्ट के साथ उनके मूल्यों के साथ आधार सेटिंग्स फ़ाइल default_settings.cfg शुरू करते हैं।

हम config_from_files configure_from_files() , config_for_unittests configure_from_files() जैसे फ़ंक्शंस के साथ utils.config मॉड्यूल बनाते हैं, जो विभिन्न स्थितियों के लिए सेटिंग्स के साथ एक ऑब्जेक्ट वापस करते हैं। /etc/my-project.cfg configure_from_files() एक कैस्केडिंग फ़ाइल खोज का आयोजन करता है: default_settings.cfg , ~/.my-project.cfg , /etc/my-project.cfg और शायद कहीं और। यह सब परियोजना पर निर्भर करता है।

गणना की गई सेटिंग्स का मूल्यांकन कॉन्फ़िगरेशन ऑब्जेक्ट की असेंबली में अंतिम चरण के रूप में किया जाता है।

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

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