एक्सएमएल दिन की भाषा प्रतीत होता है, लेकिन यह सुरक्षित नहीं है (समस्याओं का पता लगाने के लिए बाहरी उपकरण के बिना) और आप एक्सएमएल में तर्क कर रहे हैं। क्यों न केवल उसी परियोजना में इसे बाकी परियोजना के रूप में करें। यदि यह जावा है तो आप केवल एक कॉन्फ़िगर जार बना सकते हैं और इसे कक्षापथ पर रख सकते हैं।कोड में निर्भरता इंजेक्शन कॉन्फ़िगरेशन करने में क्या गलत है?
मुझे कुछ गहरा याद आना चाहिए।
कोड में कॉन्फ़िगरेशन डी के मुख्य नकारात्मक पक्ष यह है कि आप अपनी कॉन्फ़िगरेशन को बदलने के लिए एक पुनर्मूल्यांकन को मजबूर करते हैं। बाहरी फ़ाइलों का उपयोग करके, पुन: कॉन्फ़िगर करना रनटाइम परिवर्तन बन जाता है। एक्सएमएल फाइलें आपके कोड और कॉन्फ़िगरेशन के बीच अतिरिक्त अलगाव भी प्रदान करती हैं, जो कि बहुत से लोग अत्यधिक मूल्यवान हैं।
यह परीक्षण, रखरखाव, रिमोट सिस्टम पर अद्यतन करने के लिए आसान बना सकता है। हालांकि, कई भाषाओं के साथ, आप प्रश्न में कोड की गतिशील लोडिंग का उपयोग कर सकते हैं और कुछ डाउनसाइड्स से बच सकते हैं, इस मामले में फायदे कम हो जाते हैं ।
मुझे लगता है कि एक पुलिस बाहर तर्क। 99% समय, यदि आप अपनी डी कॉन्फ़िगरेशन को बदलना चाहते हैं, तो यह एक ऐसा परिवर्तन है जो इतना गहरा हो जाता है कि आपको किसी भी तरह की पुन: संकलन की आवश्यकता है। और जब तक आप अपनी कॉन्फ़िगरेशन कक्षाओं को अलग से पैकेज करते हैं, तब तक एक XML फ़ाइल को संपादित करने और कॉन्फ़िगरेशन-परीक्षण के साथ कॉन्फ़िगर-परीक्षण को बदलने के बीच बहुत कम अंतर होता है। दूसरी ओर लाभ एक ऐसी भाषा से निपट रहे हैं जो वास्तव में पठनीय है, और एक है जिसके साथ हमारे पास काम करने के लिए अत्यधिक विकसित उपकरणों के बोतलबंद हैं। –
(जैसा कि लगता है कि "हमलावर" के रूप में काफी दूर आने का मतलब नहीं है, मैंने आपको वोट दिया क्योंकि यही कारण है कि इसके लिए एक्सएमएल का उपयोग किया जाता है। मैं वास्तव में दृश्य से सहमत नहीं हूं) –
हे, मैं नहीं करता जरूरी हमेशा इसके साथ सहमत हैं। मेरे वर्तमान प्रोजेक्ट में, हम XML बनाम कोड बनाम डीआई कॉन्फ़िगरेशन (प्लस ओआरएम कॉन्फ़िगरेशन) करते हैं, क्योंकि यह हमारे लिए समझ में आता है। हालांकि, यह अक्सर एक बार तर्क दिया जाता है, और इसका स्थान होता है, इसलिए मैं इसका उल्लेख करता हूं। निजी तौर पर, मैं कोड में कॉन्फ़िगरेशन पसंद करता हूं क्योंकि आप अपनी कॉन्फ़िगरेशन फ़ाइलों के रनटाइम चेक पर भरोसा करने के बजाय संकलन समय जांच प्राप्त करते हैं, लेकिन यह व्यक्तिगत प्राथमिकता है, और सीधे प्रश्न का उत्तर नहीं है। –
कोड में कॉन्फ़िगरेशन करने के साथ आंतरिक रूप से गलत कुछ भी नहीं है, यह केवल इतना है कि कुछ अलगाव प्रदान करने के लिए एक्सएमएल का उपयोग करना प्रवृत्ति है।
एक व्यापक धारणा है कि किसी भी तरह से XML में आपकी कॉन्फ़िगरेशन होने से आपको परिवर्तन के बाद पुनर्निर्माण करने से बचाया जाता है। मेरे अनुभव में वास्तविकता यह है कि आपको बदले गए एक्सएमएल फाइलों (वेब विकास के मामले में) को वितरित करने के लिए एप्लिकेशन को दोबारा मरम्मत और पुन: नियोजित करने की आवश्यकता है, ताकि आप इसके बजाय कुछ जावा "कॉन्फ़िगरेशन" फ़ाइलों को आसानी से बदल सकें। यो बस एक्सएमएल फाइलों को वेब सर्वर पर छोड़ दें और रीफ्रेश करें, लेकिन पर्यावरण में मैं काम करता हूं, अगर हमने किया तो लेखा परीक्षा उपयुक्त होगी।
मेरी बात में एक्सएमएल कॉन्फ़िगरेशन का उपयोग करने वाली मुख्य बात डेवलपर्स को निर्भरता इंजेक्शन और चिंताओं को अलग करने के बारे में सोचने के लिए मजबूर कर रही है। वसंत (दूसरों के बीच) में, यह आपके एओपी प्रॉक्सी और इस तरह के लटकाने के लिए एक सुविधाजनक हुक भी प्रदान करता है। इन दोनों को जावा कॉन्फ़िगरेशन में हासिल किया जा सकता है, यह केवल कम स्पष्ट है जहां रेखाएं खींची जाती हैं और प्रवृत्ति सीधे निर्भरता और स्पेगेटी कोड को पुन: पेश करने के लिए हो सकती है।
जानकारी के लिए, कोड में कॉन्फ़िगरेशन करने की अनुमति देने के लिए Spring project है।
स्प्रिंग जावा कॉन्फ़िगरेशन प्रोजेक्ट (लघु के लिए जावाकॉन्फिग) स्प्रिंग आईओसी कंटेनर को कॉन्फ़िगर करने के लिए एक प्रकार-सुरक्षित, शुद्ध-जावा विकल्प प्रदान करता है। जबकि एक्सएमएल व्यापक रूप से उपयोग किए जाने वाले कॉन्फ़िगरेशन दृष्टिकोण है, वसंत की बहुमुखी प्रतिभा और मेटाडाटा-आधारित बीन परिभाषाओं के आंतरिक हैंडलिंग का मतलब है कि एक्सएमएल कॉन्फ़िगरेशन के विकल्प लागू करना आसान है।
स्प्रिंग प्रोजेक्ट लिंक के लिए धन्यवाद। पूरी तरह से अनजान था। –
आपका स्वागत है, हालांकि यह ध्यान देने योग्य है कि यह अभी तक 1.0 रिलीज –
एक्सएमएल तर्क नहीं है, और यह प्रोग्रामिंग भाषा होने से बहुत दूर है।
एक्सएमएल डेटा को डेटा को समझने और संशोधित करने के तरीके में स्टोर करने के लिए उपयोग किया जाता है।
क्या आप कहते हैं, अक्सर इसका उपयोग परिभाषाओं को स्टोर करने के लिए किया जाता है, न कि व्यावसायिक तर्क।
पर सहमत नहीं है, यह होना चाहिए, लेकिन वसंत ऋतु में यह उससे कहीं अधिक है। सशर्त रूप से बीन्स इंजेक्ट करना संभव है और इसलिए एक्सएमएल फ़ाइल में तर्क है। –
मार्टिन Fowler बहुत अच्छी तरह से यहाँ इस निर्णय को कवर:
http://martinfowler.com/articles/injection.html
plagiarize करने के लिए आग्रह करता हूं ... बचना बस खंड "कोड या विन्यास फाइल" पढ़ा जाना।
यह खराब है क्योंकि यह परीक्षण को कठिन बनाता है।
यदि आप निर्भरता प्राप्त करने के लिए कोड लिख रहे हैं और getApplicationContext() जैसी विधियों का उपयोग कर रहे हैं, तो आप निर्भरता इंजेक्शन के लाभों के कुछ को फेंक रहे हैं।
जब आपकी ऑब्जेक्ट्स और सेवाओं को बनाने या प्राप्त करने के बारे में जानने की आवश्यकता नहीं है, जिन संसाधनों पर वे निर्भर हैं, वे अधिक निर्भरता से उन निर्भरताओं के साथ मिलकर हैं।
लूज युग्मन का मतलब आसान इकाई परीक्षण है। यदि आपको अपनी सभी निर्भरताओं को तुरंत चालू करने की आवश्यकता है तो जूनिट में कुछ हासिल करना मुश्किल है। जब एक वर्ग अपनी निर्भरताओं के बारे में धारणाओं को छोड़ देता है, तो परीक्षण के उद्देश्य के लिए असली लोगों के स्थान पर नकली वस्तुओं का उपयोग करना आसान होता है।
इसके अलावा, अगर आप getAplicationContext() और अन्य कोड आधारित डी तकनीकों का उपयोग करने के आग्रह का विरोध कर सकते हैं, तो आप (कभी-कभी) वसंत ऑटोवॉयरिंग पर भरोसा कर सकते हैं जिसका अर्थ है कि कम कॉन्फ़िगरेशन कार्य भी है। कॉन्फ़िगरेशन काम करता है कि कोड में या एक्सएमएल में थकाऊ है, है ना?
यदि आप इसे कैसे कार्यान्वित करेंगे, तो आप निर्भरता इंजेक्शन नहीं कर रहे हैं। भले ही आप कॉन्फ़िगरेशन के लिए एक्सएमएल का उपयोग कर रहे हों, फिर भी आपको अपनी बीन फैक्ट्री बनाने की जरूरत है। –
दरअसल, मैं getAplicationContext() का उपयोग करने के खिलाफ बहस कर रहा हूं। – nont
आपने अपने प्रश्न पर एक टिप्पणी में वसंत का उल्लेख किया है, ताकि सुझाव दिया जा सके कि आपको इस तथ्य में रुचि हो सकती है कि स्प्रिंग 3 आपको express your application contexts in Java rather XML देता है।
यह मस्तिष्क-बेंडर का थोड़ा सा है, लेकिन आपके सेम की परिभाषा, और उनकी अंतर-निर्भरता जावा में की जा सकती है। यह अभी भी कॉन्फ़िगरेशन और तर्क के बीच एक साफ अलगाव रखता है, लेकिन रेखा थोड़ी अधिक धुंधली हो जाती है।
एक्सएमएल ज्यादातर डेटा (संज्ञा) प्रारूप है। कोड ज्यादातर एक प्रसंस्करण (क्रिया) प्रारूप है। डिज़ाइन परिप्रेक्ष्य से, यह आपके कॉन्फ़िगरेशन को एक्सएमएल में समझने में समझ में आता है यदि यह ज्यादातर संज्ञाएं (पते, मूल्य सेटिंग्स, आदि) और कोड है, यदि यह अधिकतर क्रियाएं हैं (प्रसंस्करण झंडे, हैंडलर कॉन्फ़िगरेशन इत्यादि)।
मेरे अनुभव में, विकास टीम और आधारभूत संरचना टीम के बीच घनिष्ठ संचार को अक्सर जारी करके बढ़ावा दिया जा सकता है। जितना अधिक आप रिलीज करते हैं, उतना ही आप वास्तव में जानते हैं कि आपके वातावरण के बीच भिन्नता क्या है। यह आपको अनावश्यक कॉन्फ़िगरेशन को हटाने की अनुमति देता है।
कॉन्वे के कानून के लिए एक अनुशासन यहां लागू होता है - आपकी कॉन्फ़िगरेशन फ़ाइलें आपके ऐप को नियोजित किए गए परिवेशों की विविधता के समान होती हैं (नियोजित या वास्तविक)।
जब मेरे पास आंतरिक अनुप्रयोगों को तैनात करने वाली एक टीम है, तो मैं सभी पर्यावरण संबंधी चिंताओं (कनेक्शन पूल, आदि) के लिए कोड में कॉन्फ़िगरेशन की दिशा में ड्राइव करता हूं, और सभी पर्यावरण कॉन्फ़िगरेशन (उपयोगकर्ता नाम, कनेक्शन स्ट्रिंग्स, आईपी पते) के लिए फ़ाइलों में कॉन्फ़िगर करता हूं। यदि विभिन्न वातावरणों में अलग-अलग वास्तुकला संबंधी चिंताएं हैं, तो मैं उन्हें एक वर्ग में समाहित कर दूंगा, और कॉन्फ़िगरेशन फ़ाइलों का वह वर्गनाम हिस्सा बनाउंगा - उदा।
container.config = FastInMemoryConfigurationForTesting container.config = ProductionSizedConfiguration
इन कुछ सामान्य विन्यास का उपयोग करेगा, लेकिन को पार कर जाएगी/वास्तुकला कि जगह की जरूरत के उन हिस्सों की जगह में से हर एक।
हालांकि यह हमेशा उचित नहीं है। ऐसी कई चीजें हैं जो आपकी पसंद को प्रभावित करती हैं:
1) प्रत्येक उत्पादन वातावरण में सफलतापूर्वक तैनात होने से पहले एक नई बूंद जारी करने में कितना समय लगता है और आपको उस पर्यावरण (चक्र समय) 2 पर प्रतिक्रिया प्राप्त होती है) भिन्नता तैनात वातावरण में 3) उत्पादन वातावरण से प्राप्त प्रतिक्रिया की शुद्धता।
तो, जब आपके पास एक ग्राहक है जो आपके ऐप को अपनी देव टीमों को तैनाती के लिए वितरित करता है, तो आपको अपने ऐप को और अधिक कॉन्फ़िगर करने योग्य बनाना होगा, अगर आप इसे स्वयं जीते हैं। आप अभी भी कोड में कॉन्फ़िगरेशन पर भरोसा कर सकते हैं, लेकिन इसके लिए लक्ष्य दर्शकों को आपके कोड को समझने की आवश्यकता है। यदि आप एक सामान्य कॉन्फ़िगरेशन दृष्टिकोण (उदा। वसंत) का उपयोग करते हैं, तो आप अंतिम उपयोगकर्ताओं को उनके उत्पादन में मुद्दों को अनुकूलित करने और कामकाज के लिए आसान बनाते हैं।
लेकिन एक रूब्रिक है: कॉन्फ़िगरेशन योग्यता संचार के लिए एक विकल्प है।
"कॉन्फ़िगरेशन" से आपका क्या मतलब है? –
मैंने पाया कि आप क्या खो रहे हैं: buzzword अनुपालन। ;-) –
वसंत में, कॉन्फ़िगरेशन आमतौर पर एक्सएमएल फ़ाइल अनुप्रयोग Context.xml –