पुराने वसंत, अधिक संदर्भ है

वसंत के साथ काम करने वाले कई वर्षों के लिए, मैंने एक अजीब पैटर्न देखा: प्रत्येक नए संस्करण में संदर्भ को कॉन्फ़िगर करने का एक नया तरीका जोड़ा जाता है। आइए याद करें कि यह कैसा था:

• पहले वसंत में, विन्यास एक्सएमएल-ई में विशेष रूप से लिखा जा सकता था। (ClassPathXmlApplicationContext ("reference.xml"))
• दूसरे में (2.5 से अधिक सटीक), एनोटेशन के माध्यम से संदर्भ बनाना संभव हो गया। (एनोटेशन कॉनफिग एपिलेशन कॉन्टेक्स्ट ("पैकेज.नाम"))
• तीसरे वसंत में एक जावा विन्यास जोड़ा गया। (एनोटेशन कॉनफिग एपिलेशन कॉन्टेक्स्ट (JavaConfig.class))
• चौथे ने भी परंपरा को बनाए रखा और दिसंबर 2013 से इसे ग्रूप स्क्रिप्ट (GenericGroovyApplicationContext ("reference.groovy") का उपयोग करके कॉन्फ़िगर किया जा सकता है

विभिन्न कंपनियों में प्रशिक्षणों का परामर्श और संचालन, मैंने इन कॉन्फ़िगरेशन विधियों के लिए एक बहुत अलग दृष्टिकोण देखा। बड़ी कंपनियां, अक्सर "काम - स्पर्श न करें" के सिद्धांत पर जी रही हैं, फिर भी पुराने एक्सएमएल-कॉन्फ़िगरेशन को संजोना, उन्हें गुणा करना और उन्हें नए डिब्बे के साथ खिलाना जारी है। "लेकिन सब कुछ यहाँ केंद्रीकृत है!" उनके आर्किटेक्ट चिल्लाते हैं, xml-God के लिए 100,500-हजारवीं पंक्ति जोड़ते हैं।
छोटी कंपनियों, प्रौद्योगिकी नवाचारों के साथ रखने की कोशिश कर रहा है, निर्दयता से पुराने एक्सएमएल को जलाते हैं, एनोटेशन पर वे सब कुछ लिख सकते हैं, और वे जावा कॉन्फिगरेशन पर क्या नहीं कर सकते हैं। और वे पहले से ही अपने हाथों को रगड़ रहे हैं, साथ आने की कोशिश कर रहे हैं, और वे अब खांचे पर कॉन्फ़िगरेशन कहाँ चिपकाएंगे।



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

और सत्य कहाँ है? क्या यह हमेशा बीच में है?
आइए जानने की कोशिश करते हैं ...

आरंभ करने के लिए, आइए बिन घोषणा रणनीतियों की तुलना करें।

आइए क्लासिक XML-a से शुरू करें:

<beans....> <bean class="com.inwhite.spring.compare.CoolDaoImpl" id="coolDao"/> <bean id ="coolService" class="com.inwhite.spring.compare.CoolServiceImpl" init-method="init" destroy-method="closeResources" scope="prototype"> <property name="dao" ref="coolDao"/> </bean> </beans> 

अब एक ही बात है, लेकिन एनोटेशन के साथ

 @Repository public class CoolDaoImpl implements CoolDao { @Override public void doCRUD() { //some logic here } } @Service @Scope(BeanDefinition.SCOPE_PROTOTYPE) public class CoolServiceImpl implements CoolService { @Autowired private CoolDao dao; @PostConstruct public void init() { //init logic here } @PreDestroy public void closeResources() { //close resources here } @Override public void doWork() { dao.doCRUD(); } } 

एक बार फिर, लेकिन जावा विन्यास के साथ:

 @Configuration public class JavaConfig { @Bean public CoolDao dao(){ return new CoolDaoImpl(); } @Bean(initMethod = "init", destroyMethod = "closeResources") @Scope(BeanDefinition.SCOPE_PROTOTYPE) public CoolService coolService(){ CoolServiceImpl service = new CoolServiceImpl(); service.setDao(dao()); return service; } } 

और अंत में, नाली पर एक ही बात:

 beans { coolDao(CoolDaoImpl) coolService(CoolService){bean-> bean.scope = 'prototype' bean.initMethod = 'init' bean.destroyMethod = 'closeResources' } } 

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

इस बीच, चलो वसंत 4 से पहले आए नुकसान और लाभों पर चर्चा करते हैं।



अंतिम पंक्ति को पढ़ने के बाद, गंभीर आलोचकों ने पहले से ही एक नोट बना लिया है, वे कहते हैं कि हां, लेख के लेखक को फैक्ट्री बीन्स, स्पेल और सभी प्रकार के ट्रिकी प्रोफाइल के बारे में पता नहीं है ... लेकिन चलो ईमानदार रहें, इस तालिका में XML ने काम किया है और बहुत सारे प्लसस हैं, और उनकी पृष्ठभूमि के खिलाफ हैं यह प्लस दूर की कौड़ी लगेगा। स्पेल बहुत सीमित है, और फैक्टरी बीन्स एक्सएमएल-ए का हिस्सा नहीं हैं। और ईमानदारी से, यहां तक ​​कि सबसे उत्साही एक्सएमएल-एक प्रशंसक ने शायद ही इसे एक प्रोग्रामिंग भाषा के रूप में चुना होगा।

एक और सवाल जो अक्सर प्रशिक्षणों के दौरान पूछा जाता है: "कॉन्फ़िगरेशन बदलते समय क्यों नहीं recompile - यह एक प्लस है? उसके बाद परीक्षण किए बिना उत्पादन पर सेम के कार्यान्वयन को बदलने की हिम्मत कौन करेगा? और सभी प्रकार की छोटी चीजें, जैसे कि नाम, पासवर्ड और पोर्ट, को केवल एक मालिकाना फ़ाइल में रखा जा सकता है, जिनमें से कुछ भी फिर से जमा किए बिना सामग्री को बदला जा सकता है। ”

यहाँ मेरे अभ्यास से एक मामला बताना उचित होगा, जो किसी भी तरह इस तरह से हकदार हो सकता है:

कैसे JBoss के साथ XML ने पार्टी को बचाया

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

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

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

मेरे लिए सौभाग्य से, यह बीन xml-e में पंजीकृत था। फिर निम्नलिखित बातचीत हुई:
“प्रोडक्शन कंप्यूटर पर जाएं, JBoss / server / default / तैनात फ़ोल्डर खोलें, वहां idi.ear फ़ाइल ढूंढें और इसे खोलें। इसका क्या मतलब है, कैसे? ठीक है, इसका नाम बदलकर ज़िप करें और इसे खोलें। ठीक है, META-INF फ़ोल्डर वहाँ देखें? क्या यह applicationContext.xml है? इसमें जाओ, वहाँ SchedulerFactoryBean पाते हैं और एक datacarTrigger थोड़ा कम है। इस लाइन पर टिप्पणी करें। इसका क्या मतलब है, कैसे? कोई बात नहीं, इसे मिटा दो। ठीक है, अब रिकॉर्ड करें, बंद करें, वापस नाम बदलें और सर्वर को एक नए तरीके से चालू करें। "

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

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

इस तरह के एक वास्तुकार का शुरू में मतलब होता है कि xml संग्रह (युद्ध, कान) के बाहर स्थित होगा, और जहाँ इसे प्राप्त करना आसान है। और सबसे अधिक संभावना है, इस दृष्टिकोण का उपयोग करने वाली कंपनियों में, विशेष परीक्षणों और रोलबैक के साथ इस तरह की गतिशीलता के लिए कैद एक पूरा पारिस्थितिकी तंत्र है।

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

जावा कॉन्फ़िगरेशन का एक और छोटा लेकिन अभी भी लाभ प्रदर्शन है। हम सभी जानते हैं, स्कूल से, कि "प्रतिबिंब धीमा हो जाता है।" और XML-e या एनोटेशन में लिखी गई बीन्स का उपयोग करके बनाया जाएगा। यदि वे सभी सिंगलटन हैं, तो यह इतना महत्वपूर्ण नहीं है: बूटस्ट्रैप का समय बस थोड़ा बढ़ जाएगा। हालाँकि, यदि आपका प्रोग्राम लगातार प्रोटोटाइप बनाता है, तो रिफ्लेक्शन वांछनीय नहीं है। खैर, जावा में कॉन्फ़िगरेशन के साथ, प्रतिबिंब का उपयोग नहीं किया जाता है। बीन्स को नियमित जावा कोड में बनाया जाता है।

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

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

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

परिणाम

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

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

ग्रूवी पर कॉन्फ़िगर करें

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

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

इस दौरान, लड़ाई जारी है, मैं यह सुझाव देने के लिए उद्यम करूंगा कि एक्सएमएल के खिलाफ युद्ध कैसे समाप्त होगा। आइए तस्वीर को फिर से देखें और पुरानी फिल्म को याद करें:


श्वार्जनेगर, बेशक, आखिरकार जीत गए, लेकिन किस कीमत पर ...

ठीक है, अगर कोई लड़ाई को जारी रखना चाहता है, तो मेरी रिपोर्ट पर आओ: स्प्रिंग द रिपर , जो गंभीरता से अपने कौशल को बढ़ाना चाहता है - स्प्रिंग टू सीनियर्स ट्रेनिंग