2008-10-17 10 views
9

वसंत में आप applicationContext.xml को एक कन्स्ट्रक्टर का आह्वान करके एक बीन शुरू कर सकते हैं, या आप बीन पर गुण सेट कर सकते हैं। दोनों दृष्टिकोणों के बीच व्यापार बंद क्या हैं? क्या यह एक कन्स्ट्रक्टर (जो एक विधि में आवश्यक सब कुछ रखने के अनुबंध को लागू करता है) बेहतर है या यह सभी गुणों के लिए बेहतर है (जो आपको इकाई परीक्षण के दौरान केवल चुनिंदा रूप से इंजेक्ट करने के लिए लचीलापन देता है।)एक बीन शुरू करने का सबसे अच्छा तरीका क्या है?

क्या व्यापार बंद हैं (एक बीन लिखने के बीच जो एक प्रारंभिक राज्य स्थापित करने के लिए एक कन्स्ट्रक्टर का उपयोग करता है, या गुणों का उपयोग कर सकता है और शायद बाद में प्रॉपर्टीज() विधि)?

उत्तर

15

मुझे यकीन नहीं है कि एक बीन शुरू करने के लिए "सर्वश्रेष्ठ" तरीका है। मुझे लगता है कि प्रत्येक के लिए पेशेवर और विपक्ष हैं, और स्थिति के आधार पर, एक या दूसरा उचित हो सकता है। यह निश्चित रूप से एक विस्तृत सूची नहीं है, लेकिन यहां कुछ चीजों पर विचार करना है।

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

दूसरी ओर, रचनाकारों का उपयोग अक्सर टेलीस्कोपिंग समस्या का कारण बनता है। कई बार आपको कई अलग-अलग रचनाकारों की आवश्यकता होगी, जिनमें से अधिकतर किसी अन्य निर्माता का सुपरसैट होगा। अक्सर यह सुविधा के लिए हैं। उदाहरण के लिए: यह है कि मैं बहुत ज्यादा पसंद तथाकथित "बढ़ाया" बिल्डर JavaOne में जोश बलोच द्वारा प्रस्तुत पैटर्न है करने के लिए

public class Person { 
    public Person(String name) { ... } 
    public Person(String name, String phone) { ... } 
    public Person(String name, String phone, String email) { ... } 
} 

एक वैकल्पिक। आप इसे अपनी पुस्तक "प्रभावी जावा, द्वितीय संस्करण" में देख सकते हैं। यदि आप पैटर्न का उपयोग करने के तरीके को देखते हैं, तो यह आपके "AfterProperties" विधि समस्या को भी हल करेगा। निर्माता पैटर्न गारंटी देगा कि ऑब्जेक्ट सही ढंग से प्रारंभ किया गया है।

यहाँ एक अतिरिक्त ब्लॉग पोस्ट पैटर्न पर चर्चा है: http://www.screaming-penguin.com/node/7598

मुझे यकीन है कि यह आपकी वसंत आवश्यकता में फिट बैठता है नहीं कर रहा हूँ, लेकिन सामान्य तौर पर, मैं बिल्डर के एक बड़े प्रशंसक हूँ।

+0

+1 - वास्तव में अच्छा जवाब –

+0

मुझे आपका उत्तर पसंद है, लेकिन आपके लिंक मर गए हैं:/ –

+0

धन्यवाद मैक्सिम, मैंने पोस्ट को एक लिंक के साथ अपडेट किया जो अभी भी बनी हुई है। :-) – lycono

3

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

सेटर इंजेक्शन का उपयोग करते समय, मैं प्रारंभिक विधि की पहचान करने के लिए @PostConstruct एनोटेशन का उपयोग करना पसंद करता हूं। इसमें afterProperties() विधि की तुलना में वसंत ढांचे के लिए कमजोर युग्मन शामिल है (वास्तव में, मुझे लगता है कि यह afterPropertiesSet() है)। एक और विकल्प <bean> तत्व की init विधि विशेषता है।

2

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

यह आपको सेटर्स और/या कन्स्ट्रक्टर बनाने और बहुत सारी कॉन्फ़िगरेशन बनाने का बोझ बचाता है। एक छोटी सी उदाहरण:

public class MyPersonBean { 
    @Autowired 
    private PersonManager personManager; 

    public void doSomething() { 
    this.personManager.doSomething(); 
    } 
} 

और अपने कॉन्फ़िग फ़ाइल में:

<context:annotation-config/> 

Autowiring, प्रकार के आधार पर किया जाता है, इसलिए यदि आप प्रकार PersonManager की एक सेम है, यह यह टिप्पणी किए गए क्षेत्र में इंजेक्षन जाएगा । मामले में आप उस प्रकार आप @Qualifier एनोटेशन का उपयोग कर सकते उन्हें अलग से बताने की अधिक सेम है ...

आप Spring Reference Documentation

में autowiring के बारे में अधिक जानकारी प्राप्त कर सकते मैं घटक के साथ संयोजन में @Autowired उपयोग शुरू कर दिया - मेरी पिछली परियोजना में स्कैनिंग और मुझे कहना होगा कि मैंने अपनी स्प्रिंग कॉन्फ़िगरेशन फ़ाइलों में से 90% से अधिक छुटकारा पा लिया है।

0

तालमेल:

कंस्ट्रक्टर: लाभ: बहुत ही सरल, esp हो सकता है। प्रारंभ करने के लिए तीन या कम गुणों के साथ। चिंता के लिए एक शॉट, नहीं/न्यूनतम अतिरिक्त विन्यास।

कमियां: एकाधिक कंस्ट्रक्टर्स, कई स्थितियों कंस्ट्रक्टर्स नहीं ली गई है के लिए बनाया जाना चाहिए ताकि कक्षाएं सुपर() फोन और पिछले व्यवहार अनुमति देने के लिए डुप्लिकेट कंस्ट्रक्टर्स प्रदान करनी चाहिए।

सेटर्स: लाभ: बच्चों को सेटर्स का उत्तराधिकारी होता है, इसलिए संपत्तियों को निर्माण के बाद व्यवहार को प्रभावित करने के लिए आसानी से ओवरराइड किया जा सकता है। एकाधिक विधि हस्ताक्षर किए बिना एक एकीकृत फैशन में एकाधिक गुण निर्दिष्ट किए जा सकते हैं (जावाबीन्स सम्मेलन)

दोष: प्रत्येक सेटटर को प्रत्येक संपत्ति के लिए स्पष्ट रूप से बुलाया जाना चाहिए। बड़ी संख्या में गुणों को स्पष्ट रूप से सेट करने वाले कुछ वर्गों की ओर ले जाता है।

0

तुम भी उपयोग कर सकते हैं @Resource@Autowired के बजाय autowire के लिए, यह autowire byname की तरह थोड़े से काम करता है ताकि आप अगर वहाँ एक ही प्रकार के साथ और अधिक सेम हैं (ओएफसी तुम भी है कि @Qualifier साथ संभाल कर सकते हैं चिंता करने की ज़रूरत नहीं है, लेकिन मैं केवल एक बीन की विशेषता का वर्णन करने की सिफारिश करेगा)। यह वास्तव में आपके उपयोग के मामले पर निर्भर करता है कि किस तरह से सबसे अच्छा होगा ताकि आपको अपनी स्थिति के लिए इसका मूल्यांकन करना होगा और बाद में फैसला करना होगा।

 संबंधित मुद्दे

  • कोई संबंधित समस्या नहीं^_^