में @service और @repository एनोटेशन का आदान-प्रदान करते हैं तो क्या होगा यदि हमें डीएओ कार्यान्वयन में सेवा कार्यान्वयन और @repository के अंदर @service का उपयोग करने की आवश्यकता क्यों है। वसंत एमवीसी में @service और @repository एनोटेशन का आदान-प्रदान करते समय कोई समस्या नहीं होती है।यदि हम वसंत एमवीसी
documentaion@Repository, @Service, @Controller के अनुसार सभी समानार्थी शब्द हैं। वे सभी @Component एनोटेशन की सिर्फ विशेषज्ञता। इसलिए, आम तौर पर, वे दूसरे के एक आइसटेड का उपयोग किया जा सकता है। लेकिन ... आपको यह नहीं करना चाहिए।
पहला कारण: इस एनोटेशन में से कोई भी एप्लिकेशन में आपके घटक के भूमिका को स्पष्ट करता है। दिखाता है - क्या यह घटक नियंत्रक, सेवा या डेटा परत से संबंधित है।
दूसरा कारण: इनमें से कुछ एनोटेशन विभिन्न स्प्रिंग मॉड्यूल द्वारा अलग-अलग संसाधित होते हैं। उदाहरण के लिए, Spring Data JPA@Repository को संसाधित करेगा, और इस एनोटेशन द्वारा चिह्नित किसी भी इंटरफ़ेस को कार्यान्वित करने के साथ प्रतिस्थापित करने का प्रयास करेगा। वसंत भी इस तरह के वर्गों में स्वचालित अपवाद अनुवाद लागू करेगा। एक और उदाहरण, Spring Web MVC प्रक्रिया @Controller, और URL मैपिंग में इसके साथ चिह्नित कक्षाओं का उपयोग करें।
वास्तव में, भविष्य के संस्करणों में, वसंत के कुछ मॉड्यूल @Service को विशेष रूप से संसाधित कर सकते हैं। @Component जितना सरल नहीं है।
यह भी संभव है कि @Repository, @Service, और @Controller स्प्रिंग फ्रेमवर्क के भविष्य के रिलीज में अतिरिक्त अर्थ विज्ञान ले सकते हैं: क्यों प्रलेखन सलाह है कि है। इस प्रकार, यदि आप अपनी सेवा परत के लिए @Component या @Service का उपयोग करने के बीच चयन कर रहे हैं, तो @ सेवा स्पष्ट रूप से बेहतर विकल्प है।
यह इस बात पर निर्भर करता है कि आप ढांचे के शेष के लिए क्या उपयोग करते हैं। सिद्धांत में @Service और @Repository एनोटेशन के रूप में कुछ भी नहीं बदलता है मूल रूप से @Component एनोटेशन हैं। @Controller या @Endpoint (स्प्रिंग डब्ल्यूएस के लिए और अधिक हैं) के लिए भी यही कहा जा सकता है।
हालांकि वे एक वर्ग (एक सेवा, एक भंडार) के इरादे को व्यक्त करते हैं और उपयोगकर्ता को यह स्पष्ट करता है कि कक्षा किस वर्ग से संबंधित है।
हालांकि यदि आप लेनदेन प्रबंधन के लिए स्प्रिंग का उपयोग भी करते हैं तो @Repository उस वर्ग में adding exception translation के लिए एक ट्रिगर भी है (reference guide भी देखें)।
हालांकि कुछ भी में है तो इसे तोड़ने के लिए शायद कुछ बिंदु पर होगा।
इससे शायद आपके लेन-देन खराब हो जाएंगे। एक सेवा को उन लेनदेन को पारित करने की आवश्यकता होती है जिन्हें डीएओ को प्रचार की आवश्यकता होती है। दोनों घटक हैं इसलिए एक बीन का निर्माण एक समस्या नहीं होगी। – TheLostMind