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

स्प्रिंग बीन स्कोप को समझना

स्प्रिंग में, एक बीन एक ऑब्जेक्ट है जिसे स्प्रिंग आईओसी (कंट्रोल का उलटा) कंटेनर द्वारा तत्काल, इकट्ठा और प्रबंधित किया जाता है। बीन स्कोप बीन के जीवनचक्र को संदर्भित करता है - बीन इंस्टेंस कैसे और कब बनाए जाते हैं, और वे कितने समय तक चलते हैं।

स्प्रिंग कई बीन स्कोप प्रदान करता है, लेकिन मैं जिन दो पर ध्यान केंद्रित करूंगा वे हैं:

• सिंगलटन स्कोप
• प्रोटोटाइप स्कोप

प्रत्येक दायरे के अपने विशिष्ट उपयोग के मामले होते हैं, और सही को चुनने से आपके एप्लिकेशन के व्यवहार और प्रदर्शन पर महत्वपूर्ण प्रभाव पड़ सकता है।

सिंगलटन स्कोप

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

यह काम किस प्रकार करता है

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

यहां एक सरल उदाहरण दिया गया है:

@Configuration
public class AppConfig {
    @Bean
    public MyService myService() {
        return new MyService();
    }
}

इस उदाहरण में, myService() एक सिंगलटन बीन है। जब भी मैं स्प्रिंग संदर्भ से MyService बीन का अनुरोध करता हूं, मुझे वही उदाहरण मिलेगा।

सिंगलटन बीन्स के लिए केस का उपयोग करें

मैंने पाया है कि सिंगलटन स्कोप स्टेटलेस बीन्स के लिए आदर्श है - जिनमें कोई ग्राहक-विशिष्ट जानकारी नहीं होती है। उदाहरणों में शामिल हैं:

• सेवा वर्ग: आमतौर पर, इन वर्गों में व्यावसायिक तर्क होते हैं जिन्हें अलग-अलग उदाहरणों की आवश्यकता के बिना पूरे एप्लिकेशन में साझा किया जा सकता है।
• डीएओ कक्षाएं: चूंकि वे आम तौर पर डेटाबेस के साथ इंटरैक्ट करते हैं और क्लाइंट-विशिष्ट स्थिति को बनाए नहीं रखते हैं, इसलिए एक उदाहरण पर्याप्त है।

लाभ और विचार

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

प्रोटोटाइप स्कोप

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

यह काम किस प्रकार करता है

जब एक बीन को प्रोटोटाइप स्कोप के साथ परिभाषित किया जाता है, तो स्प्रिंग हर बार बीन के अनुरोध पर एक नया उदाहरण लौटाएगा। यहां बताया गया है कि मैं प्रोटोटाइप बीन को कैसे परिभाषित कर सकता हूं:

@Configuration
public class AppConfig {
    @Bean
    @Scope("prototype")
    public MyService myService() {
        return new MyService();
    }
}

इस उदाहरण में, जब भी मैं स्प्रिंग संदर्भ से MyService बीन का अनुरोध करता हूं, स्प्रिंग MyService का एक नया उदाहरण बनाएगा।

प्रोटोटाइप बीन्स के लिए केस का उपयोग करें

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

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

लाभ और विचार

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

सिंगलटन बनाम प्रोटोटाइप: सही दायरा चुनना

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

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

व्यावहारिक उदाहरण

मैं एक व्यावहारिक परिदृश्य प्रदान करता हूं जो यह स्पष्ट करने में मदद कर सकता है कि प्रत्येक दायरे का उपयोग कब करना है। मान लीजिए मैं एक ऑनलाइन शॉपिंग एप्लिकेशन बना रहा हूं।

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

मिक्सिंग स्कोप: सावधानी का एक शब्द

एक बात जो मैंने कठिन तरीके से सीखी है वह यह है कि सिंगलटन और प्रोटोटाइप बीन्स को मिलाने से अप्रत्याशित समस्याएं पैदा हो सकती हैं। उदाहरण के लिए, एक प्रोटोटाइप-स्कोप्ड बीन को सिंगलटन बीन में इंजेक्ट करने से सिंगलटन बीन हमेशा प्रोटोटाइप बीन के एक ही उदाहरण का उपयोग कर सकता है। इससे बचने के लिए, मैं आमतौर पर एक प्रदाता को इंजेक्ट करता हूं या @लुकअप एनोटेशन का उपयोग करता हूं ताकि यह सुनिश्चित किया जा सके कि हर बार जरूरत पड़ने पर प्रोटोटाइप बीन का एक नया उदाहरण बनाया जाए।

@Service
public class SingletonService {

    @Autowired
    private Provider myPrototypeServiceProvider;

    public void usePrototypeService() {
        MyPrototypeService prototypeService = myPrototypeServiceProvider.get();
        prototypeService.execute();
    }
}

इस उदाहरण में, myPrototypeServiceProvider.get() यह सुनिश्चित करता है कि MyPrototypeService का एक नया उदाहरण हर बार सिंगलटन बीन के भीतर कॉल किए जाने पर बनाया जाता है।

अलविदा !

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

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