2009-03-11 21 views
200

@Autowired का उपयोग करने के पेशेवरों और विपक्ष क्या हैं जो स्प्रिंग द्वारा वायर्ड किए जाएंगे?वसंत @Autowired उपयोग

बस स्पष्ट करने के लिए, मैं विशेष रूप से @Autowired एनोटेशन के बारे में बात कर रहा हूं, एक्सएमएल में ऑटो-वायरिंग नहीं।

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

+4

मुझे इस विषय में भी रूचि है - एक्सएमएल के बजाए एनोटेशन के माध्यम से अपने एमवीसी ऐप को कॉन्फ़िगर करना ऐसा लगता है कि इससे "यूआरएल में कौन सी क्लास मैप की गई है?" "यह कौन संभाला जा रहा है?"। मुझे एक विन्यास स्रोत –

+5

शब्द "@Autowiring" शब्द यहां गुमराह करना प्रतीत होता है।चूंकि आप एक्सएमएल कॉन्फ़िगरेशन के साथ ऑटोवॉयरिंग भी कर सकते हैं, मूल प्रश्न को "स्प्रिंग एनोटेशन का उपयोग करने के पेशेवरों और विपक्ष" के रूप में दोहराया जाना चाहिए। प्रदान किया गया उत्तर ऑटोवॉयरिंग के पहलुओं और एनोटेशन का उपयोग करने के पहलुओं पर कम केंद्रित करता है। –

+0

[वसंत @Autowired उपयोग को समझना] के संभावित डुप्लिकेट (https://stackoverflow.com/questions/19414734/understanding-spring-autowired-usage) – tkruse

उत्तर

244

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

मैं जितना संभव हो उतना ऑटो-वायरिंग का उपयोग करता हूं। मुझे यह पसंद है। जब तक बंदूक बिंदु पर धमकी नहीं दी जाती तब तक मैं पुरानी शैली के वसंत में वापस नहीं जाऊंगा। पूरी तरह से @Autowired पसंद करने के मेरे कारण समय के साथ बदल गए हैं।

अभी मुझे लगता है कि ऑटोवॉयरिंग का उपयोग करने का सबसे महत्वपूर्ण कारण यह है कि आपके सिस्टम में ट्रैक रखने के लिए एक कम अमूर्तता है। "बीन नाम" प्रभावी रूप से चला गया है। यह पता चला है कि बीन नाम केवल एक्सएमएल के कारण मौजूद है। तो अमूर्त संकेतों की एक पूर्ण परत (जहां आप बीन "बार" में बीन-नाम "foo" तार करेंगे) चला गया है। अब मैं सीधे अपने बीन में "फू" इंटरफेस को तार करता हूं, और कार्यान्वयन रन-टाइम प्रोफाइल द्वारा चुना जाता है। यह निर्भरता और कार्यान्वयन का पता लगाने पर कोड के साथ काम करने की अनुमति देता है। जब मैं अपने कोड में एक स्वायत्त निर्भरता देखता हूं तो मैं अपने आईडीई में "कार्यान्वयन पर जाएं" कुंजी दबा सकता हूं और ऊपर ज्ञात कार्यान्वयन की सूची आता है। ज्यादातर मामलों में केवल एक कार्यान्वयन होता है और मैं सीधे कक्षा में हूं। इससे कहीं अधिक सरल नहीं हो सकता है, और मुझे हमेशा बिल्कुल का कार्यान्वयन किया जा रहा है (मेरा दावा है कि विपरीत एक्सएमएल तारों के साथ सत्य के करीब है - मजाकिया कैसे आपका परिप्रेक्ष्य बदलता है!)

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

अधिकांश सिस्टम जिनके साथ मैंने कभी काम किया है, केवल एक उत्पादन रनटाइम पर्यावरण की कॉन्फ़िगरेशन है। परीक्षण के लिए अन्य विन्यास भी हो सकते हैं।

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

हम शायद ही कभी हमारे कॉन्फ़िगरेशन में क्वालीफायर का उपयोग करते हैं, और इन स्थितियों को हल करने के अन्य तरीकों को ढूंढते हैं। यह एक स्पष्ट "हानिकारक" है जिसका हम सामना करते हैं: हमने कोड को जिस तरह से कोड करने के लिए इसे ऑटोवॉयरिंग के साथ आसान तरीके से बदल दिया है: एक ग्राहक भंडार अब सामान्य Repository<Customer> इंटरफ़ेस लागू नहीं करता है लेकिन हम Repository<Customer> को इंटरफ़ेस CustomerRepository बनाते हैं। कभी-कभी उप-वर्गीकरण की बात आती है तो एक चाल या दो भी होती है। लेकिन यह आमतौर पर हमें मजबूत टाइपिंग की दिशा में इंगित करता है, जो मुझे लगता है कि लगभग हमेशा एक बेहतर समाधान होता है।

लेकिन हां, आप DI की एक विशेष शैली को जोड़ रहे हैं जो ज्यादातर वसंत करता है। हम निर्भरताओं के लिए सार्वजनिक सेटर्स को और भी नहीं बनाते हैं (इसलिए आप तर्क दे सकते हैं कि हम encapsulation/सूचना छिपाने वाले विभाग में +1 हैं) हमारे पास अभी भी हमारे सिस्टम में कुछ XML है, लेकिन xml मूल रूप से केवल विसंगतियों में शामिल है । पूर्ण ऑटोवॉयरिंग xml के साथ अच्छी तरह से एकीकृत करता है।

केवल एक चीज अब हम की जरूरत है @Component, @Autowired और आराम के लिए है एक JSR (JSR-250 की तरह) में शामिल किया जाना है, तो हम वसंत के साथ में टाई की जरूरत नहीं है। अतीत में चीजें हो रही हैं (java.util.concurrent सामान स्प्रिंग्स दिमाग में), इसलिए अगर यह फिर से हुआ तो मैं पूरी तरह से आश्चर्यचकित नहीं होगा।

+4

javax.annotation/javax.inject वसंत द्वारा समर्थित है, इसलिए आपको स्प्रिंग पर कोड निर्भरता नहीं है। –

26

मेरे लिए यहां वसंत और ऑटो-तारों के बारे में मुझे पसंद/नापसंद है।

सकारात्मक:

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

विपक्ष:

  • ऑटो तारों और टिप्पणियों का उपयोग करने आप स्प्रिंग पुस्तकालयों जहां एक्सएमएल विन्यास के साथ के रूप में आप के साथ या वसंत के बिना चलाने के लिए चुना जा सकता था पर निर्भर करता है। जैसा कि आपने कहा था, आप एक डी ढांचे से बंधे हो जाते हैं।
  • उसी समय मुझे बीन्स को 'अर्हता प्राप्त करने' में सक्षम होना पसंद है, यह मेरे लिए कोड वास्तव में गन्दा बनाता है। यदि आपको एक ही बीन को कई स्थानों पर इंजेक्ट करने की आवश्यकता है, तो मैंने एक ही स्ट्रिंग नाम को बार-बार दोहराया है। मेरे लिए यह त्रुटियों की संभावना प्रतीत होता है।

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

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

+3

एक्सएमएल कॉन्फ़िगरेशन बहुत कम बुरा हो जाता है यदि आप मुफ्त स्प्रिंगसोर्स टूल सूट का उपयोग करते हैं, जो विशेषताएं स्वत: पूर्णता, बीन ग्राफ इत्यादि –

+0

मैं पूरी तरह से ऑटो-तारों पर गन्दा हो रहा हूं और वसंत पुस्तकालयों पर निर्भर हूं! मैंने एक्सएमएल कॉन्फ़िगरेशन का कभी भी उपयोग नहीं किया है और मुझे लगता है कि मुझे शायद उस पथ को नीचे ले जाना चाहिए? – James111

4

मैंने @Autowire पर स्विच किया है। एक छोटी परियोजना के अलावा किसी अन्य चीज़ पर एक्सएमएल कॉन्फ़िगरेशन को बनाए रखना अपने स्वयं के अधिकार में एक कार्य बन गया और समझ जल्दी से खराब हो गई।

IntelliJ स्प्रिंग एनोटेशन के लिए अच्छा (सही नहीं) समर्थन प्रदान करता है।

14

हम अपने बड़े प्रोजेक्ट में @Autowire से XML कॉन्फ़िगरेशन में स्विच कर रहे हैं।समस्या बहुत कम बूटस्ट्रैप प्रदर्शन है। ऑटोवॉयरिंग स्कैनर ऑटो क्लासिंग सर्च क्लासपाथ से सभी वर्गों को लोड करता है, इसलिए, वसंत प्रारंभिकरण के दौरान बहुत से वर्ग उत्सुकता से लोड होते हैं।

+1

मुझे पता चला है कि javaconfig आंशिक संदर्भ शुरू करने के लिए एक बेहतर समाधान भी हो सकता है, जो एक बड़ी जीत है लेकिन आप रचनाकारों पर @ ऑटोवायर/@ इंजेक्ट का उपयोग करके इन्हें आसानी से जोड़ सकते हैं (दूसरे शब्दों में, कन्स्ट्रक्टर इंजेक्शन पर स्विच करें)। – krosenvold

3

इस विषय पर मेरा लेना यह है कि, xml कॉन्फ़िगरेशन कोड की स्पष्टता को कम करता है, खासकर बड़े सिस्टम में।

@ कॉम्पोनेंट जैसी टिप्पणियां चीजों को और भी बदतर बनाती हैं। यह ऑब्जेक्ट्स को म्यूटेबल बनाने के लिए डेवलपर्स को चलाता है, क्योंकि निर्भरताओं को अब अंतिम नहीं बनाया जा सकता है, क्योंकि डिफॉल्ट कन्स्ट्रक्टर को प्रदान करने की आवश्यकता है। निर्भरता को या तो सार्वजनिक सेटटर के माध्यम से इंजेक्शन दिया जाना चाहिए, या @Autowired के माध्यम से अनियंत्रित किया जाना चाहिए। [यहां तक ​​कि बदतर निर्भरता इंजेक्शन उन वर्गों से समझौता किया गया है जो उनकी निर्भरताओं को तुरंत चालू करते हैं, मैं अब भी इसे नए लिखित कोड में देखता हूं!]। अनियंत्रित मेरा मतलब है, बड़े सिस्टम में, जब इस प्रकार के कई कार्यान्वयन (या बच्चे) उपलब्ध होते हैं, तो यह समझने में बहुत अधिक शामिल होता है कि कौन से कार्यान्वयन @Autowired थे, एक जटिलता जो बग की जांच को अधिक कठिन बनाती है। इसका मतलब यह भी है कि, माना जाता है कि आपके पास परीक्षण पर्यावरण के लिए एक प्रोफ़ाइल है और दूसरा उत्पादन के लिए है, तो आपकी उत्पादन कीड़े केवल तब होती हैं जब उत्पादन में सबसे अधिक दर्द होता है, परीक्षण वातावरण में कीड़े को स्थानांतरित करने में सक्षम होने के बजाय, या इससे भी बेहतर समय संकलित करें!

मैं बीच मैदान, जहां मैं अपने विन्यास वर्ग (ते), (जावा आधारित स्प्रिंग विन्यास @Configuration का प्रयोग करके)

मैं विन्यास वर्ग (ते) में स्पष्ट रूप से मेरे सारे सेम की घोषणा घोषित करने के लिए चिपके रहते हैं। मैं केवल कॉन्फ़िगरेशन क्लास (एसएस) में @Autowired का उपयोग करता हूं, इसका उद्देश्य स्प्रिंग पर कॉन्फ़िगरेशन क्लास (एसएस)

@ कॉन्फ़िगरेशन एक विशिष्ट पैकेज में रहता है, यह एकमात्र ऐसा स्थान है जहां वसंत स्कैन रन । (यह बड़ी परियोजनाओं में काफी समय से शुरू होता है)

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

बनाए जाने के बाद वस्तुओं को बदलने की संभावनाओं को कम करने, बड़ी प्रणाली में बग को काफी कम करता है और साथ ही साथ मौजूद होने पर बग खोजने के लिए समय कम कर देता है।

ऐसा लगता है कि यह सिस्टम के विभिन्न हिस्सों के बीच बातचीत को बेहतर ढंग से डिजाइन करने के लिए डेवलपर को मजबूर करता है। समस्याएं और बग अधिक से अधिक संकलन त्रुटियां बन जाती हैं, जो बर्बाद समय को कम करती हैं और उत्पादकता में सुधार करती हैं।

1

यहाँ अनुभव
पेशेवरों

  • आसान बनाता है कॉन्फ़िगर करने के लिए है क्योंकि हम सिर्फ @Autowire एनोटेशन का उपयोग कर सकते
  • सेटर तरीकों का उपयोग करने के लिए नहीं चाहते हैं, तो वर्ग और अधिक हो जाएगा स्वच्छ

विपक्ष

  • कसकर xml फ़ाइल के लिए जोड़े को भले ही हम कार्यान्वयन को खोजने के लिए डि
  • हार्ड उपयोग कर रहे हैं (लेकिन आप अपने आप वास्तव में इस से छुटकारा पा सकते IntelliJ की तरह अच्छा IDEs का उपयोग कर यदि)

मेरी निजी के रूप में अनुभव मैंने @AutoWire एनोटेशन का उपयोग नहीं किया था, लेकिन परीक्षण मामलों में।

6

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

@Value("#{${env} == "production" ? realService : dummyService}") 
    private SomeService service; 

यह काम करना चाहिए, लेकिन नहीं एक अच्छा समाधान imho।

+0

मैंने इसके बारे में एक अलग धागा खोला, और वसंत 'प्रोफाइल 'और' @ कॉन्फ़िगरेशन 'के साथ एक समाधान है: http://blog.springsource.org/2011/02/14/spring-3-1-m1- परिचय-प्रोफ़ाइल/अन्य धागे को भी देखें: http://stackoverflow.com/questions/13490393/annotation-driven- निर्भरता- इंजेक्शन- जो भी- हैंडल- अलग-अलग वातावरण – BTakacs

1

मुझे वास्तव में एक्सएमएल के बजाय एनोटेशन के साथ लिखना अच्छा लगता है। वसंत मैनुअल और अंतिम संस्करणों के अनुसार, एक्सएमएल और एनोटेशन ने एक ही परिणाम प्राप्त किया।

  • एक्सएमएल
  • से बेकार लाइन निकालें डिबगिंग को सरल कोड: जब आप एक वर्ग खोलते हैं, तो आप वर्ग
  • में तुम्हारे पास क्या है पढ़ सकते हैं

    यह मेरी सूची

    प्रो है

  • अधिक तेजी से विकास, एक्सएमएल की 400 या अधिक लाइन वाली एक परियोजना पठनीय है?

विपक्ष:

  • मानक जावा कार्यान्वयन नहीं है, लेकिन आप @Inject है, जो एक जावा मानक एपीआई है उपयोग करने के लिए स्विच कर सकते हैं, तो सेम एक Pojo रहने
  • आप बस हर जगह उपयोग नहीं कर सकते , डीबी कनेक्शन ई इतने पर, लेकिन यह केवल एक राय है, मैं एक जगह है जहां सभी विन्यास पढ़ा पसंद है।
0

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