वसंत में @Component, @Repository & @Service एनोटेशन के बीच क्या अंतर है?

Question

क्या @Component, @Repositoryऔर @Serviceएनोटेशन का उपयोग स्प्रिंग में एक-दूसरे से किया जा सकता है या क्या वे नोटेशन डिवाइस के रूप में कार्य करने के अलावा कोई विशेष कार्यक्षमता प्रदान करते हैं?

दूसरे शब्दों में, अगर मैं एक सेवा वर्ग है और मैं से एनोटेशन को बदलने @Serviceके लिए @Component, यह अभी भी उसी तरह व्यवहार करेंगे?

या एनोटेशन भी वर्ग के व्यवहार और कार्यक्षमता को प्रभावित करता है?

Comments

Microsoft पृष्ठभूमि के साथ एक डेवलपर होने के नाते, मुझे पुराने MS SmartClientSoftwareFactory ढांचे (अब वितरित डेस्कटॉप ऐप्स के लिए एक लंबी पदावनत जटिल ढाँचा) में सेवाओं की शब्दार्थ परिभाषा याद है। उस परिभाषा ( रिच न्यूमैन द्वारा अच्छी तरह से प्रलेखित ) ने सेवाओं को स्टेटलेस पुन: प्रयोज्य वस्तुओं के रूप में परिभाषित किया, अधिमानतः सिंगलटन स्कोप के साथ, जिसका उपयोग तर्क के रूप में पारित अन्य वस्तुओं पर व्यावसायिक तर्क संचालन करने के लिए किया जाता है। मैं उसी तरह से स्प्रिंग सेवाओं को देखने के लिए प्रवृत्त हूं

— Ivaylo Slavov

कोई बात नहीं !! आपके लिए जो कुछ भी काम करता है :) मैंने हमेशा वसंत के बारे में यह नफरत की है कि वे हमेशा आपके लिए "नियम" को परिभाषित करते हैं, जो आपके आवेदन में केवल तुच्छ मूल्य जोड़ते हैं। वसंत का उल्लेख नहीं करने के लिए अपने स्वयं के विशाल ढेर के साथ आता है।

— TriCore

@ ट्रायकोर छिड़काव एक ढांचा है, परिभाषित करें कि "नियम" आपके लिए इसका काम है :)

— Walfrat

Answer 1

से वसंत प्रलेखन :

@Repositoryएनोटेशन किसी भी वर्ग उस भूमिका या भंडार (यह भी डेटा एक्सेस वस्तु या डीएओ के रूप में जाना जाता है) की स्टीरियोटाइप को पूरा के लिए एक मार्कर है। इस मार्कर के उपयोगों में अपवादों का स्वचालित अनुवाद है, जैसा कि अपवाद अनुवाद में वर्णित है ।

वसंत आगे स्टीरियोटाइप एनोटेशन प्रदान करता है: @Component, @Service, और @Controller। @Componentकिसी भी स्प्रिंग-प्रबंधित घटक के लिए एक सामान्य स्टीरियोटाइप है। @Repository, @Service, और @Controllerकी विशेषज्ञताओं हैं @Componentऔर अधिक विशिष्ट उपयोग के मामलों के लिए (में दृढ़ता, सेवा, और प्रस्तुति परतों, क्रमशः)। इसलिए, आप के साथ अपने घटक वर्गों टिप्पणी कर सकते हैं @Componentउन लोगों के साथ व्याख्या द्वारा, लेकिन, @Repository, @Service, या @Controller बजाय, अपनी कक्षाओं अधिक ठीक से उपकरण द्वारा प्रसंस्करण या पहलुओं के साथ जोड़ के लिए अनुकूल हैं।

उदाहरण के लिए, ये स्टीरियोटाइप एनोटेशन पॉइंटकट्स के लिए आदर्श लक्ष्य बनाते हैं। @Repository, @Serviceऔर @Controllerस्प्रिंग फ्रेमवर्क के भविष्य के रिलीज में अतिरिक्त शब्दार्थ भी ले जा सकते हैं। इस प्रकार, यदि आप अपनी सेवा परत का उपयोग कर @Componentया के बीच चयन कर रहे हैं, तो स्पष्ट रूप से बेहतर विकल्प है। इसी तरह, जैसा कि पहले कहा गया है, आपकी दृढ़ता परत में स्वचालित अपवाद अनुवाद के लिए पहले से ही मार्कर के रूप में समर्थित है।@Service@Service@Repository

┌──────────────┬─────────────────────────────────────────────────────┐
│ Annotation   │ Meaning                                             │
├──────────────┼─────────────────────────────────────────────────────┤
│  @Component  │ generic stereotype for any Spring-managed component │
│  @Repository │ stereotype for persistence layer                    │
│  @Service    │ stereotype for service layer                        │
│  @Controller │ stereotype for presentation layer (spring-mvc)      │
└──────────────┴─────────────────────────────────────────────────────┘

Comments

क्या एक @ebServlet में @Controller (या @Component) को जोड़ने का कोई मतलब होगा? यह एक स्प्रिंग एमवीसी नियंत्रक नहीं है, लेकिन यह वैचारिक रूप से निकटतम मैच है। सर्वलेट फिल्टर के बारे में क्या?

— रिक

क्या करता है "@ रिपॉजिटरी आपकी दृढ़ता परत में स्वचालित अपवाद अनुवाद के लिए एक मार्कर के रूप में पहले से ही समर्थित है।" क्या मतलब है?

— जैक

यह इस तथ्य की बात कर रहा है कि ये एनोटेशन AOP के लिए अच्छे लक्ष्य हैं, और जबकि अन्य एनोटेशन अभी तक एक बिंदु को परिभाषित नहीं करते हैं, वे भविष्य में ऐसा कर सकते हैं। दूसरी तरफ @Repository पहले से ही एक बिंदु के लिए एक लक्ष्य है। उस बिंदु का उपयोग अपवाद अनुवाद के लिए किया जाता है, अर्थात अधिक विशिष्ट स्प्रिंग-आधारित लोगों के लिए प्रौद्योगिकी-विशिष्ट अपवादों का अनुवाद, तंग युग्मन से बचने के लिए।

— स्टिवलो

@stivlo: मैंने वास्तव में 'स्टीरियोटाइप' शब्द को समझने की कोशिश की है, फिर भी समझ नहीं आया। क्या आप इस शब्दावली को समझने में मेरी मदद कर सकते हैं? यह बहुत मदद करता है और बहुत बहुत धन्यवाद

— प्रेमराज

@xenoterracide व्यावहारिक रूप से बहुत अंतर नहीं है। साथ एनोटेट कुछ @Service है भी एक @Component(क्योंकि @Serviceएनोटेशन के साथ ही टिप्पणी की जाती है @Component)। जहां तक ​​मुझे पता है, स्प्रिंग फ्रेमवर्क में कुछ भी स्पष्ट रूप से इस तथ्य का उपयोग नहीं करता है कि कुछ एक है @Service, इसलिए अंतर वास्तव में केवल वैचारिक है।

— जेस्पर

Answer 2

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

पहली समानता

पहले बिंदु को फिर से उजागर करने के लायक है कि बीनडिफाइनमेंट के लिए स्कैन-ऑटो-डिटेक्शन और निर्भरता इंजेक्शन के संबंध में ये सभी एनोटेशन (अर्थात, @Component, @Service, @Repository, @Controller) समान हैं। हम दूसरे के स्थान पर एक का उपयोग कर सकते हैं और अभी भी अपना रास्ता प्राप्त कर सकते हैं।

---

@Component, @Repository, @Controller और @Service के बीच अंतर

@Component

यह एक सामान्य-उद्देश्य वाला स्टीरियोटाइप एनोटेशन है जो दर्शाता है कि वर्ग एक वसंत घटक है।

विशेष क्या है @Component के बारे में
<context:component-scan> केवल स्कैन करता है@Componentऔर के लिए नहीं लग रही है@Controller,@Serviceऔर@Repositoryसामान्य रूप में। वे स्कैन किए जाते हैं क्योंकि वे स्वयं एनोटेट होते हैं@Component।

बस एक नज़र रखना @Controller, @Serviceऔर @Repositoryएनोटेशन परिभाषाएँ:

@Component
public @interface Service {
    ….
}

 

@Component
public @interface Repository {
    ….
}

 

@Component
public @interface Controller {
    …
}

इस प्रकार, यह कहना गलत नहीं है @Controller, @Serviceऔर @Repositoryविशेष प्रकार के @Componentएनोटेशन हैं। <context:component-scan>उन्हें उठाता है और अपने निम्न वर्गों को सेम के रूप में पंजीकृत करता है, जैसे कि उन्हें एनोटेट किया गया था @Component।

विशेष प्रकार के एनोटेशन भी स्कैन किए जाते हैं, क्योंकि वे खुद @Componentएनोटेशन के साथ एनोटेट होते हैं, जिसका अर्थ है कि वे भी @Componentएस हैं। यदि हम अपने स्वयं के कस्टम एनोटेशन को परिभाषित करते हैं और इसके साथ एनोटेट करते हैं @Component, तो इसके साथ स्कैन भी हो जाएगा<context:component-scan>

---

@Repository

यह इंगित करना है कि वर्ग डेटा रिपॉजिटरी को परिभाषित करता है।

@Repository के बारे में क्या खास है?

यह इंगित करने के अलावा, कि यह एनोटेशन आधारित कॉन्फ़िगरेशन है , @Repositoryकार्य प्लेटफ़ॉर्म विशिष्ट अपवादों को पकड़ना है और उन्हें स्प्रिंग के एकीकृत अनियोजित अपवाद के रूप में फिर से फेंकना है। इसके लिए, हमें यह प्रदान किया जाता है PersistenceExceptionTranslationPostProcessorकि हमें अपने स्प्रिंग के एप्लिकेशन संदर्भ में इस तरह जोड़ना होगा:

<bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor"/>

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

---

@Controller

@Controllerएनोटेशन इंगित करता है कि एक विशेष वर्ग एक नियंत्रक की भूमिका में कार्य करता है। @Controllerएनोटेशन, उसकी व्याख्या वर्ग के लिए एक स्टीरियोटाइप के रूप में कार्य में अपनी भूमिका का संकेत है।

@Controller के बारे में क्या खास है?

हम किसी भी अन्य के साथ इस एनोटेशन परिवर्तन नहीं कर सकते @Serviceया @Repository, भले ही वे एक ही लग रही है। डिस्पैचर ने एनोटेट वर्गों को स्कैन किया @Controllerऔर @RequestMappingउनके भीतर एनोटेशन के साथ एनोटेट तरीकों का पता लगाता है। हम उपयोग कर सकते हैं @RequestMappingकेवल उन तरीकों जिसका वर्गों द्वारा एनोटेट में पर / @Controllerऔर यह होगा नहीं के साथ काम @Component, @Service, @Repositoryआदि ...

_{नोट: यदि किसी वर्ग को किसी वैकल्पिक विधि के माध्यम से पहले से ही पंजीकृत किया जाता है, जैसे कि के माध्यम से @Beanया के माध्यम से @Component, @Serviceआदि ... एनोटेशन, तो @RequestMappingक्लास को @RequestMappingएनोटेशन के साथ भी एनोटेट किया जा सकता है । लेकिन यह एक अलग परिदृश्य है।}

---

@सर्विस

@Service बीन्स व्यापारिक तर्क रखते हैं और रिपॉजिटरी लेयर में कॉल के तरीके बताते हैं।

@ सेवा के बारे में क्या खास है?

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

---

और क्या?

उपरोक्त के समान, भविष्य में वसंत के लिए विशेष कार्यशीलता जोड़ सकते हैं @Service, @Controllerऔर @Repositoryउनके स्तर पर सम्मेलनों के आधार पर। इसलिए, यह हमेशा एक अच्छा विचार है कि सम्मेलन का सम्मान करें और इसे परतों के अनुरूप उपयोग करें।

Comments

यदि JPA का पता चलता है तो 'PersistenceExceptionTranslationPostProcessor' अपने आप पंजीकृत हो जाएगा।

— ओल्गा

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

— NodziGames

तब @Service एनोटेशन का मतलब Hibernate (पर्सिस्टेंस लेयर) के लिए होता है, इसके अलावा DI फीचर के बारे में क्या है कि फ़िस्टिंग के लिए पर्सेंट लेयर प्रॉक्सी के बारे में और संबंधित डीटीओ को किसी प्रकार की एंटिटी को मैप करने के बारे में क्या? दृढ़ता परत में गतिशीलता के लिए यह परत बहुत महत्वपूर्ण है। अगर कोई गहराई से जानता है कि यह जेपीए को कैसे प्रभावित करता है तो यह बहुत मददगार होगा)))

— मूसा

@Controllerएनोटेशन के बारे में कुछ छोटी गलत जानकारी है । यह आवश्यक नहीं है अगर वर्ग के साथ एनोटेट किया जाता है @RequestMappingऔर किसी भी तरह से इस वर्ग का बीन बनाया जाता है। @Controller OR के साथ एनोटेट किया गया कोई भी सेम @RequestMappingस्प्रिंग MVC के अनुरोध मैपिंग में भाग लेगा। यह उदाहरण के लिए नियंत्रकों को प्रोग्रामेटिक रूप से बनाने के लिए उपयोगी हो सकता है (जैसे कि @Beanविधियों का उपयोग करके ) और उसी समय स्प्रिंग को रोकने के लिए उन्हें पैकेज स्कैन द्वारा बनाने की कोशिश करना (यदि पैकेज को स्कैनिंग से बाहर नहीं किया जा सकता है)।

— रुस्लान Stelmachenko

यह शीर्ष मतदान का जवाब होना चाहिए - सभी सवालों के जवाब देता है और काफी गहरा जाता है। @stivlo ने पहले ओपी प्रश्न के बारे में बहुत कुछ नहीं बताया - तकनीकी अंतर।

— kiedysktos

Answer 3

वे लगभग समान हैं - उनमें से सभी का मतलब है कि वर्ग एक स्प्रिंग बीन है। @Service, @Repositoryऔर @Controllerविशेष हैं @Component। आप उनके साथ विशिष्ट कार्य करना चुन सकते हैं। उदाहरण के लिए:

• @Controller सेम का उपयोग वसंत-एमवीसी द्वारा किया जाता है
• @Repository बीन्स दृढ़ता अपवाद अनुवाद के लिए पात्र हैं

एक और बात यह है कि आप घटकों को अलग-अलग परतों में शब्दबद्ध रूप से नामित करते हैं।

एक चीज जो @Componentप्रदान करती है वह यह है कि आप इसके साथ अन्य एनोटेशन को एनोटेट कर सकते हैं, और फिर उन्हें उसी तरह से उपयोग कर सकते हैं @Service।

उदाहरण के लिए हाल ही में मैंने बनाया:

@Component
@Scope("prototype")
public @interface ScheduledJob {..}

तो सभी वर्गों के साथ एनोटेट @ScheduledJobवसंत सेम हैं और इसके अलावा क्वार्ट्ज नौकरियों के रूप में पंजीकृत हैं। आपको बस कोड प्रदान करना होगा जो विशिष्ट एनोटेशन को संभालता है।

Comments

@ कैमपेंट का मतलब केवल एक स्प्रिंग बीन है, क्या इसके लिए कोई अन्य उद्देश्य है?

— कपिल दास

@ कंटेनर बीन्स स्प्रिंग कंटेनर द्वारा ऑटो डिटेक्टेबल होते हैं। आपको कॉन्फ़िगरेशन फ़ाइल में बीन को परिभाषित करने की आवश्यकता नहीं है, यह स्वचालित रूप से स्प्रिंग द्वारा रनटाइम पर पता लगाया जाएगा।

— आकाश ५२ Ak Ak

मैं जेनेरिक @Component का काफी शौकीन हूं ... विशेष रूप से कॉम्बो में @Scope (प्रॉक्सीमोड = ScopedProxyMode.//MODE) के साथ

— एडी बी

Answer 4

@Component के बराबर है

<bean>

@ सेवा, @ कंट्रोलर, @ रिपोसिटरी = {@Component + कुछ और विशेष कार्यक्षमता}

इसका मतलब है कि सेवा, नियंत्रक और भंडार कार्यात्मक रूप से समान हैं।

तीन एनोटेशन का उपयोग आपके एप्लिकेशन में "लेयर्स" को अलग करने के लिए किया जाता है ,

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

अब आप पूछ सकते हैं कि उन्हें अलग क्यों करें: (मुझे लगता है कि आप AOP-Aspect ओरिएंटेड प्रोग्रामिंग जानते हैं)

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

तो आप DAO तरीकों के बाद "आसपास", "पहले" या "DAO" की लॉगिंग कर सकते हैं। आप ऐसा कर सकते हैं क्योंकि आपके पास पहले स्थान पर एक डीएओ था। आपने जो कुछ हासिल किया है वह चिंताओं या कार्यों का पृथक्करण है।

कल्पना कीजिए कि अगर केवल एक एनोटेशन @Controller होता, तो इस घटक में डिस्पैचिंग, बिजनेस लॉजिक और एक्सेसिंग डेटाबेस सभी मिश्रित होते, इसलिए गंदा कोड होता!

ऊपर उल्लिखित एक बहुत ही सामान्य परिदृश्य है, तीन एनोटेशन का उपयोग करने के कई और मामले हैं।

Comments

मुझे एक मूल प्रश्न मिला - क्या स्प्रिंग सिस्टम द्वारा एनोटेशन का उपयोग किया जाता है या वे प्रोग्रामर के लिए यह याद रखने के लिए हैं कि कोड के वे टुकड़े क्या करते हैं?

— user107986

@ user107986 वे मुख्य रूप से प्रोग्रामर को एप्लिकेशन में परतों को याद रखने के लिए हैं। हालाँकि @Respositoryइसमें स्वचालित अपवाद अनुवाद सुविधा भी है। जैसे कि जब कोई अपवाद होता @Repositoryहै, तो आमतौर पर उस अपवाद के लिए एक हैंडलर होता है और डीएओ वर्ग में ट्राई कैच ब्लॉक जोड़ने की कोई आवश्यकता नहीं होती है। यह PersistenceExceptionTranslationPostProcessor के साथ प्रयोग किया जाता है

— ओलिवर

क्या आप कृपया एक नमूना कोड लिख सकते हैं कि सभी "@ रिपॉजिटरी" वर्ग के लिए एक संयुक्त अंक कैसे लिखें। या तो हम अभिव्यक्ति का उपयोग करते हैं या बीन नाम का उपयोग करते हैं लेकिन हम यह कैसे कह सकते हैं कि यह सलाह सभी "@Repository" कक्षाओं पर लागू होगी। मैं इस का नमूना प्राप्त करने की कोशिश कर रहा था, लेकिन खोजने में सक्षम नहीं था। आपकी मदद वास्तव में सराहना की जाती है।

— मोनी

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

— Cod3Citrus 1

Answer 5

वसंत @Componentमें @Service, @Controllerऔर, @Repositoryस्टीरियोटाइप एनोटेशन हैं जिनका उपयोग किया जाता है:

@Controller: जहां अपने प्रस्तुति पृष्ठ से अनुरोध मैपिंग किया गया है अर्थात प्रस्तुति परत किसी भी अन्य फ़ाइल में नहीं जाएगी, यह सीधे @Controllerक्लास में जाती है और @RequestMappingएनोटेशन में अनुरोधित पथ की जाँच करती है जो कि आवश्यक होने पर विधि कॉल से पहले लिखा जाता है।

@Service: सभी व्यावसायिक तर्क यहां दिए गए हैं अर्थात डेटा से संबंधित गणना और सभी। यह व्यवसाय परत का एनोटेशन है जिसमें हमारे उपयोगकर्ता सीधे हठ विधि नहीं कहते हैं इसलिए यह इस एनोटेशन का उपयोग करके इस पद्धति को कॉल करेगा। यह उपयोगकर्ता के अनुरोध के अनुसार @Repository का अनुरोध करेगा

@Repository: यह आवेदन की दृढ़ता परत (डेटा एक्सेस लेयर) है जो डेटाबेस से डेटा प्राप्त करने के लिए उपयोग किया जाता है। यानी डेटाबेस से संबंधित सभी ऑपरेशन रिपॉजिटरी द्वारा किए जाते हैं।

@Component - घटक स्टीरियोटाइप के साथ अपने अन्य घटकों (उदाहरण के लिए REST संसाधन कक्षाएं) को एनोटेट करें।

इंगित करता है कि एक एनोटेट वर्ग एक " घटक " है " है। एनोटेशन-आधारित कॉन्फ़िगरेशन और क्लासपैथ स्कैनिंग का उपयोग करते समय ऐसी कक्षाओं को ऑटो-डिटेक्शन के लिए उम्मीदवार माना जाता है।

अन्य श्रेणी-स्तरीय एनोटेशन को एक घटक की पहचान करने के रूप में माना जा सकता है, आमतौर पर एक विशेष प्रकार का घटक: जैसे @Repository एनोटेशन या AspectJ के @Aspect एनोटेशन।

Comments

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

— dtc

सभी व्यावसायिक तर्क सेवाओं में नहीं जाने चाहिए! DDD के संदर्भ में, सेवाओं में केवल डोमेन तर्क होना चाहिए जो एक से अधिक इकाइयों को प्रभावित करता है। उत्तर देखें stackoverflow.com/a/41358034/238134

— deamon

@deamon हां, लेकिन इसका विकासकर्ताओं के दृष्टिकोण पर निर्भर करता है

— हर्षल पाटिल

@HarshalPatil आप बेशक सेवाओं में सभी व्यावसायिक तर्क के साथ एक आवेदन लिख सकते हैं, लेकिन यह एक एनीमिक डोमेन मॉडल को जन्म देगा और यह संस्थाओं पर बाधाओं और निरंतरता को लागू करने के लिए अनावश्यक रूप से कठिन बना देगा।

— बहमन

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

— मीलो

Answer 6

स्प्रिंग 2.5 आगे के स्टीरियोटाइप एनोटेशन का परिचय देता है: @Component, @Service और @Controller। @Component किसी भी स्प्रिंग-प्रबंधित घटक के लिए एक सामान्य स्टीरियोटाइप के रूप में कार्य करता है; जबकि, @ रिपॉजिटरी, @ सेवा और @ कंट्रोलर अधिक विशिष्ट उपयोग के मामलों (उदाहरण के लिए, दृढ़ता, सेवा और प्रस्तुति परतों में, क्रमशः) के लिए @Component की विशेषज्ञता के रूप में काम करते हैं। इसका मतलब यह है कि आप अपने घटक वर्गों को @Component के साथ एनोटेट कर सकते हैं, लेकिन उन्हें @Repository, @Service, या @Controller के साथ एनोटेट करके, आपकी कक्षाएं टूल द्वारा प्रसंस्करण के लिए अधिक उपयुक्त हैं या पहलुओं से संबद्ध होकर। उदाहरण के लिए, ये स्टीरियोटाइप एनोटेशन पॉइंटकट्स के लिए आदर्श लक्ष्य बनाते हैं। बेशक, यह भी संभव है कि @Repository, @Service, और @Controller स्प्रिंग फ्रेमवर्क के भविष्य के रिलीज़ में अतिरिक्त शब्दार्थ ले सकते हैं। इस प्रकार, यदि आप अपनी सेवा परत के लिए @Component या @ सेवा का उपयोग करने के बीच कोई निर्णय ले रहे हैं, तो @ सेवा स्पष्ट रूप से बेहतर विकल्प है। इसी तरह, जैसा कि ऊपर कहा गया है, @ रिपॉजिटरी आपकी दृढ़ता परत में स्वचालित अपवाद अनुवाद के लिए एक मार्कर के रूप में पहले से ही समर्थित है।

@Component – Indicates a auto scan component.
@Repository – Indicates DAO component in the persistence layer.
@Service – Indicates a Service component in the business layer.
@Controller – Indicates a controller component in the presentation layer.

संदर्भ: - स्प्रिंग डॉक्यूमेंटेशन - क्लासपैथ स्कैनिंग, प्रबंधित घटक और जावा का उपयोग करके कॉन्फ़िगरेशन लिखना

Answer 7

तकनीकी तौर पर @Controller, @Service, @Repositoryसब एक ही हैं। इन सभी का विस्तार होता है @Component।

स्प्रिंग स्रोत कोड से:

इंगित करता है कि एक एनोटेट वर्ग एक "घटक" है। एनोटेशन-आधारित कॉन्फ़िगरेशन और क्लासपैथ स्कैनिंग का उपयोग करते समय ऐसी कक्षाओं को ऑटो-डिटेक्शन के लिए उम्मीदवार माना जाता है।

हम सीधे उपयोग कर सकते हैं @Componentहर सेम के लिए है, लेकिन बेहतर समझ और एक बड़े आवेदन के रख-रखाव के लिए, हम का उपयोग करें @Controller, @Service, @Repository।

प्रत्येक एनोटेशन का उद्देश्य:

1. @Controller-> इसके साथ एनोटेट की गई क्लासेस का उद्देश्य क्लाइंट की तरफ से अनुरोध प्राप्त करना है। पहला अनुरोध डिस्पैचर सर्वलेट के लिए आता है, जहां से यह @RequestMappingएनोटेशन के मूल्य का उपयोग करके विशेष नियंत्रक के अनुरोध को पारित करता है ।
2. @Service-> इसके साथ एनोटेट किए गए वर्गों का उद्देश्य डेटा में हेरफेर करना है, जो हमें क्लाइंट से प्राप्त होता है या डेटाबेस से प्राप्त होता है। डेटा के साथ सभी हेरफेर इस परत में किया जाना चाहिए।
3. @Repository-> इसके साथ एनोटेट किए गए वर्गों को डेटाबेस से जोड़ने का इरादा है। इसे DAO (डेटा एक्सेस ऑब्जेक्ट) लेयर भी माना जा सकता है। यह परत केवल सीआरयूडी (बनाने, पुनर्प्राप्त करने, अद्यतन करने, हटाने) के संचालन तक ही सीमित होनी चाहिए। यदि किसी भी हेरफेर की आवश्यकता है, तो डेटा को @ सेवा की परत पर वापस भेजा जाना चाहिए।

अगर हम उनकी जगह (उपयोग के स्थान पर इंटरचेंज) करते @Repositoryहैं@Controller ) , तो हमारा आवेदन ठीक काम करेगा।

तीन अलग-अलग का उपयोग करने का मुख्य उद्देश्य @annotationsएंटरप्राइज एप्लिकेशन को बेहतर मॉड्यूलरिटी प्रदान करना है।

Comments

इंटरचेंजिंग स्थानों को बदलने से आपका क्या मतलब है? controller and repository

— आशीष कांबले

Answer 8

डेटाबेस कनेक्शन परिप्रेक्ष्य से उपयोग @Serviceऔर @Repositoryएनोटेशन महत्वपूर्ण हैं।

1. उपयोग @Service DB कनेक्शन के सभी अपने वेब सेवा प्रकार के लिए
2. @Repositoryअपने सभी संग्रहित डीबी कनेक्शन के लिए उपयोग करें

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

Comments

क्या DBR ऑपरेशंस के बजाय RestAPI कॉल के लिए @Repository का उपयोग किया जा सकता है?

— नईम

@ तकनीकी रूप से आप सेवाओं के रूप में नियंत्रकों और रिपॉजिटरी के रूप में सेवाओं की व्याख्या कर सकते हैं, निर्भरता इंजेक्शन बस एक ही काम करेगा। लेकिन आप ऐसा कभी क्यों करेंगे? यदि यह डेटाबेस संस्थाओं के साथ काम नहीं करता है - यह एक रिपॉजिटरी नहीं है, और @Repositoryविशेष रूप से दृढ़ता परत के साथ काम करने के लिए डिज़ाइन किया गया है। यदि आप बाकी एपीआई के साथ काम कर रहे हैं - आप डीटीओ के साथ काम कर रहे हैं, न कि डीएओ के साथ।

— बेन

Answer 9

@Repository @Service और @Controller @Component की विशेषज्ञता रूप में कार्य करता है कि आधार पर अधिक विशिष्ट उपयोग के लिए आप @Component को @Service जगह ले सकता है लेकिन इस मामले में आप ढीला विशेषज्ञता है।

1. **@Repository**   - Automatic exception translation in your persistence layer.
2. **@Service**      - It indicates that the annotated class is providing a business service to other layers within the application.

Answer 10

ये सभी एनोटेशन स्टीरियो प्रकार के एनोटेशन के प्रकार हैं, इन तीन एनोटेशनों के बीच का अंतर है

• अगर हम @Component को जोड़ते हैं तो यह बताता है कि वर्ग की भूमिका एक घटक वर्ग है इसका मतलब यह है कि यह एक वर्ग है जिसमें कुछ तर्क हैं, लेकिन यह नहीं बताता है कि कोई वर्ग विशेष रूप से व्यवसाय या दृढ़ता या नियंत्रक तर्क से युक्त है या नहीं, इसलिए हम इसका उपयोग नहीं करते हैं सीधे यह @Component एनोटेशन
• यदि हम @ सेवा की व्याख्या जोड़ते हैं तो यह बताता है कि व्यावसायिक तर्क से युक्त वर्ग की भूमिका
• यदि हम वर्ग के शीर्ष पर @ रिपॉजिटरी जोड़ते हैं तो यह बताता है कि एक वर्ग जिसमें दृढ़ता तर्क है
• यहाँ @Component @ Service, @ Repository और @Controller एनोटेशन के लिए आधार एनोटेशन है

उदाहरण के लिए

package com.spring.anno;
@Service
public class TestBean
{
    public void m1()
    {
       //business code
    }
}

package com.spring.anno;
@Repository
public class TestBean
{
    public void update()
    {
       //persistence code
    }
}

• जब भी हम कहते हैं @Serviceया @Repositroyया @Controllerडिफ़ॉल्ट रूप से एनोटेशन @Componentएनोटेशन वर्ग के शीर्ष पर अस्तित्व के लिए जा रहा है

Answer 11

स्प्रिंग, वे कर रहे हैं ऑटो घटक एनोटेशन स्कैन के चार अलग अलग प्रकार प्रदान करता है @Component, @Service, @Repositoryऔर@Controller । तकनीकी रूप से, उनके बीच कोई अंतर नहीं है, लेकिन प्रत्येक ऑटो घटक स्कैन एनोटेशन का उपयोग एक विशेष उद्देश्य के लिए और परिभाषित परत के भीतर किया जाना चाहिए।

@Component: यह एक बुनियादी ऑटो घटक स्कैन एनोटेशन है, यह इंगित करता है कि एनोटेट वर्ग एक ऑटो स्कैन घटक है।

@Controller: एनोटेट वर्ग इंगित करता है कि यह एक नियंत्रक घटक है, और मुख्य रूप से प्रस्तुति परत पर उपयोग किया जाता है।

@Service: यह इंगित करता है कि एनोटेट वर्ग व्यावसायिक परत में एक सेवा घटक है।

@Repository: आपको इस एनोटेशन को दृढ़ता परत के भीतर उपयोग करने की आवश्यकता है, यह डेटाबेस रिपॉजिटरी की तरह काम करता है।

@Componentअपनी कक्षा को एनोटेट करते समय एक अधिक विशिष्ट रूप का चयन करना चाहिए क्योंकि इस एनोटेशन में आगे जाने वाला विशिष्ट व्यवहार हो सकता है।

Answer 12

हम जावा मानक के अनुसार इसका उत्तर दे सकते हैं

का उल्लेख करते हुए JSR-330, जो अब वसंत द्वारा समर्थित है, आप केवल @Namedबीन (किसी तरह @Named=@Component) को परिभाषित करने के लिए उपयोग कर सकते हैं । इस मानक के अनुसार इस प्रकार लगता है लकीर के फकीर परिभाषित करने के लिए किसी काम का नहीं है कि वहाँ (जैसे @Repository, @Service,@Controller ) श्रेणियों सेम करने के लिए।

लेकिन वसंत उपयोगकर्ता विशिष्ट उपयोग के लिए अलग-अलग इन एनोटेशन का उदाहरण देते हैं:

1. डेवलपर्स को सक्षम के लिए एक बेहतर श्रेणी को परिभाषित करने में मदद करें। यह श्रेणीकरण कुछ मामलों में सहायक हो सकता है। (उदाहरण के लिए जब आप उपयोग कर रहे हों aspect-oriented, तो ये एक अच्छे उम्मीदवार हो सकते हैंpointcuts )
2. @Repository एनोटेशन आपके बीन में कुछ कार्यक्षमता जोड़ देगा (आपकी बीन दृढ़ता परत के लिए कुछ स्वचालित अपवाद अनुवाद)।
3. यदि आप स्प्रिंग MVC का उपयोग कर रहे हैं, तो @RequestMappingकेवल उन्हीं वर्गों को जोड़ा जा सकता है , जिनके द्वारा एनोटेट किया गया है @Controller।

Comments

अपने तीसरे बिंदु के बारे में। यह सच नहीं है। मैं सेवा वर्ग के तहत विधियों में भी @RequestMapping एनोटेशन जोड़ सकता हूं (मेरा मतलब है कि @Service के साथ एनोटेट की गई कक्षाएं)।

— राहुल गुप्ता

Answer 13

@Component के साथ अन्य घटकों का उल्लेख करें, उदाहरण के लिए REST संसाधन कक्षाएं।

@Component
public class AdressComp{
    .......
    ...//some code here    
}

@Component किसी भी स्प्रिंग प्रबंधित घटक के लिए एक सामान्य स्टीरियोटाइप है।

@Controller, @Service और @Repository विशिष्ट उपयोग मामलों के लिए @Component के विशेषज्ञ हैं।

वसंत में @Component

Answer 14

वहाँ कोई अंतर नहीं है @Component, @Service, @Controller, @Repository। @Componentहमारे एमवीसी के घटक का प्रतिनिधित्व करने के लिए सामान्य एनोटेशन है। लेकिन हमारे MVC एप्लिकेशन के हिस्से के रूप में कई घटक होंगे जैसे सर्विस लेयर घटक, दृढ़ता परत घटक और प्रस्तुति परत घटक। इसलिए उन्हें अलग करने के लिए स्प्रिंग लोगों ने अन्य तीन एनोटेशन भी दिए हैं।

• दृढ़ता परत घटकों का प्रतिनिधित्व करने के लिए: @Repository
• सेवा परत घटकों का प्रतिनिधित्व करने के लिए: @Service
• प्रस्तुति परत घटकों का प्रतिनिधित्व करने के लिए: @Controller
• या फिर आप उन @Componentसभी के लिए उपयोग कर सकते हैं।

Answer 15

भले ही हम @Component या @Repository या @service को इंटरचेंज करें

यह एक ही व्यवहार करेगा, लेकिन एक पहलू यह है कि यदि हम घटक या @ सेवा का उपयोग करते हैं, तो वे रिपॉजिटरी के बजाय डीएओ से संबंधित कुछ विशिष्ट अपवाद को पकड़ने में सक्षम नहीं होंगे।

Answer 16

स्प्रिंग 4 में, नवीनतम संस्करण:

@ रिपॉजिटरी एनोटेशन किसी भी वर्ग के लिए एक मार्कर है जो एक रिपॉजिटरी की भूमिका या स्टीरियोटाइप (जिसे डेटा एक्सेस ऑब्जेक्ट या डीएओ के रूप में भी जाना जाता है) को पूरा करता है। इस मार्कर के उपयोगों में धारा 20.2.2, "अपवाद अनुवाद" में वर्णित अपवादों का स्वचालित अनुवाद है।

स्प्रिंग आगे स्टीरियोटाइप एनोटेशन प्रदान करता है: @Component, @Service, और @Controller। @Component किसी भी स्प्रिंग-प्रबंधित घटक के लिए एक सामान्य स्टीरियोटाइप है। @Repository, @Service और @Controller क्रमशः विशिष्ट सेवा मामलों के लिए @Component के विशेषज्ञ हैं, उदाहरण के लिए, दृढ़ता, सेवा और प्रस्तुति परतों में क्रमशः। इसलिए, आप अपने घटक वर्गों को @Component के साथ एनोटेट कर सकते हैं, लेकिन उनके बजाय @Repository, @Service, या @Controller के साथ एनोटेट करके, आपकी कक्षाएं टूल द्वारा प्रसंस्करण के लिए अधिक उपयुक्त हैं या पहलुओं से संबद्ध हैं। उदाहरण के लिए, ये स्टीरियोटाइप एनोटेशन पॉइंटकट्स के लिए आदर्श लक्ष्य बनाते हैं। यह भी संभव है कि @Repository, @Service, और @Controller स्प्रिंग फ्रेमवर्क के भविष्य के रिलीज़ में अतिरिक्त शब्दार्थ ले सकते हैं। इस प्रकार, यदि आप अपनी सेवा परत के लिए @Component या @ सेवा का उपयोग करने के बीच चयन कर रहे हैं, तो @ सेवा स्पष्ट रूप से बेहतर विकल्प है। इसी तरह, जैसा कि ऊपर कहा गया है, @ रिपॉजिटरी आपकी दृढ़ता परत में स्वचालित अपवाद अनुवाद के लिए एक मार्कर के रूप में पहले से ही समर्थित है।

Answer 17

@Component : आप एक क्लास एनोटेट करते हैं@Component , यह हाइबरनेट बताता है कि यह बीन है।

@ रिपॉजिटरी : आप एक वर्ग को एनोटेट करते हैं @Repository, यह हाइबरनेट बताता है कि यह एक डीएओ क्लास है और इसे डीएओ क्लास मानते हैं। इसका अर्थ है कि यह अनियंत्रित अपवाद (DAO विधियों से फेंका गया) वसंत में अनुवाद के लिए योग्य बनाता हैDataAccessException ।

@ सेवा : यह हाइबरनेट बताता है कि यह एक सेवा वर्ग है जहाँ आपके पास होगा@Transactional सेवा परत एनोटेशन होंगे इसलिए हाइबरनेट इसे सेवा घटक के रूप में मानता है।

प्लस @Serviceकी अग्रिम है @Component। मान लें कि बीन क्लास का नाम है CustomerService, चूंकि आपने XML बीन कॉन्फ़िगरेशन तरीका नहीं चुना है , इसलिए आपने बीन @Componentको इसे बीन के रूप में इंगित करने के लिए एनोटेट किया है । इसलिए सेम ऑब्जेक्ट CustomerService cust = (CustomerService)context.getBean("customerService");को डिफ़ॉल्ट रूप से प्राप्त करते समय , स्प्रिंग घटक के पहले चरित्र को कम करेगा - 'ग्राहक सेवा' से 'ग्राहक सेवा' तक। और आप इस घटक को 'customerService' नाम से पुनः प्राप्त कर सकते हैं। लेकिन अगर आप @Serviceबीन क्लास के लिए एनोटेशन का उपयोग करते हैं तो आप एक विशिष्ट बीन नाम प्रदान कर सकते हैं

@Service("AAA")
public class CustomerService{

और आप सेम वस्तु प्राप्त कर सकते हैं

CustomerService cust = (CustomerService)context.getBean("AAA");

Answer 18

@Component शीर्ष स्तर जेनेरिक एनोटेशन है जो एनोटेट बीन को स्कैन करने और डीआई कंटेनर में उपलब्ध करने के लिए बनाता है

@Repository विशेष एनोटेशन है और यह DAO वर्गों से सभी अनियंत्रित अपवादों को परिवर्तित करने की सुविधा लाता है

@Serviceविशेष एनोटेशन है। यह अब तक कोई नई सुविधा नहीं लाता है, लेकिन यह सेम के इरादे को स्पष्ट करता है

@ कंट्रोलर विशेष एनोटेशन है जो बीन एमवीसी को अवगत कराता है और आगे के एनोटेशन जैसे उपयोग की अनुमति देता है @RequestMapping और सभी

यहाँ अधिक विवरण हैं

Answer 19

ए @Serviceटू को स्प्रिंग डॉक्यूमेंटेशन,

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

यदि आप eric evans द्वारा डोमेन संचालित डिज़ाइन को देखते हैं,

एक सेवा एक इंटरफ़ेस के रूप में पेश किया जाने वाला एक ऑपरेशन है, जो बिना एनकैप्सिटिव राज्य के मॉडल में अकेला खड़ा है, जैसा कि ENTITIES और VALUE OBJECTS करते हैं। तकनीकी ढांचे में सेवा एक सामान्य पैटर्न है, लेकिन वे डोमेन परत में भी लागू हो सकते हैं। नाम सेवा अन्य वस्तुओं के साथ संबंध पर जोर देती है। ENTITIES और VALUE OBJECTS के विपरीत, इसे विशुद्ध रूप से परिभाषित किया जाता है कि यह ग्राहक के लिए क्या कर सकता है। एक सेवा का नाम एक गतिविधि के बजाय एक संज्ञा के रूप में रखा जाता है - एक संज्ञा के बजाय एक क्रिया। एक सेवा में अभी भी एक सार, जानबूझकर परिभाषा हो सकती है; यह सिर्फ एक वस्तु की परिभाषा से अलग स्वाद है। एक सेवा में अभी भी एक परिभाषित जिम्मेदारी होनी चाहिए, और यह जिम्मेदारी और इसे पूरा करने वाले इंटरफ़ेस को डोमेन मॉडल के हिस्से के रूप में परिभाषित किया जाना चाहिए। ऑपरेशन नाम UBIQUITOUS LANGUAGE से आने चाहिए या इसमें शुरू किए जाने चाहिए। पैरामीटर और परिणाम डोमेन ऑब्जेक्ट होना चाहिए। सेवाओं का विवेकपूर्ण तरीके से उपयोग किया जाना चाहिए और उनके सभी व्यवहारों के ENTITIES और VALUE OBJECTS को पट्टी करने की अनुमति नहीं दी जानी चाहिए। लेकिन जब कोई ऑपरेशन वास्तव में एक महत्वपूर्ण डोमेन कॉन्सेप्ट होता है, तो एक MODEL-DRIVEN DESIGN का एक स्वाभाविक हिस्सा एक सेवा बन जाता है। मॉडल में एक सेवा के रूप में घोषित किया गया, बल्कि एक ऐसी वस्तु के रूप में, जो वास्तव में किसी चीज का प्रतिनिधित्व नहीं करता है, स्टैंडअलोन ऑपरेशन किसी को भी भ्रमित नहीं करेगा। एक सेवा मॉडल-डिजाइन डिजाइन का एक स्वाभाविक हिस्सा है। मॉडल में एक सेवा के रूप में घोषित किया गया, बल्कि एक ऐसी वस्तु के रूप में, जो वास्तव में किसी चीज का प्रतिनिधित्व नहीं करता है, स्टैंडअलोन ऑपरेशन किसी को भी भ्रमित नहीं करेगा। एक सेवा मॉडल-डिजाइन डिजाइन का एक स्वाभाविक हिस्सा है। मॉडल में एक सेवा के रूप में घोषित किया गया, बल्कि एक ऐसी वस्तु के रूप में, जो वास्तव में किसी चीज का प्रतिनिधित्व नहीं करता है, स्टैंडअलोन ऑपरेशन किसी को भी भ्रमित नहीं करेगा।

और Repositoryएरिक इवांस के अनुसार,

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

Answer 20

व्हाट्स-ऑफ-द-डिफरेंस-कंपोनेंट-रिपॉजिटरी-सर्विस-एनोटेशन को समझाने के लिए अच्छे पर्याप्त उत्तर यहां दिए गए हैं। के बीच का अंतर साझा करना चाहूंगा@Controller & @RestController

@Controller बनाम RestController

@RestController:

• यह एनोटेशन स्वचालित रूप से @Controllerजोड़ता @Controllerऔर एनोटेशन का एक विशेष संस्करण है @ResponseBody। इसलिए हमें @ResponseBodyअपने मैपिंग के तरीकों को नहीं जोड़ना है। इसका मतलब @ResponseBodyहै कि डिफ़ॉल्ट सक्रिय है।
• यदि आप उपयोग @RestControllerकरते हैं तो आप एक दृश्य नहीं लौटा सकते हैं ( Viewresolverस्प्रिंग / स्प्रिंग-बूट में उपयोग करके )
• @RestControllerभी के जवाब धर्मान्तरित JSON/XML automaticallyके रूप में @ResponseBodyकुछ ऐसा है जो शरीर में हो सकता है के लिए वापस आ वस्तुओं बनाता है,e.g. JSON or XML

---

@Controller

• @Controllerस्प्रिंग MVC नियंत्रक के रूप में वर्गों को चिह्नित करने के लिए उपयोग किया जाता है। यह एनोटेशन सिर्फ एक विशेष संस्करण है @Componentऔर यह क्लासपैथ स्कैनिंग के आधार पर नियंत्रक कक्षाओं को ऑटो-डिटेक्ट करने की अनुमति देता है।
• @Controller आप स्प्रिंग वेब MVC में एक दृश्य वापस कर सकते हैं।

अधिक विस्तृत दृश्य

Answer 21

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

Answer 22

रूढ़ियों का स्पष्टीकरण:

• @Service- @ सेवा के साथ अपने सभी सेवा वर्गों को एनोटेट करें। यह परत कार्य की इकाई को जानती है। आपके सभी व्यावसायिक तर्क सेवा वर्गों में होंगे। आम तौर पर लेन-देन के तहत सर्विस लेयर के तरीके कवर होते हैं। आप सेवा पद्धति से कई DAO कॉल कर सकते हैं, यदि एक लेनदेन विफल हो जाता है तो सभी लेनदेन रोलबैक होने चाहिए।
• @Repository- @Repository के साथ अपने सभी DAO वर्गों को एनोटेट करें। आपके सभी डेटाबेस एक्सेस लॉजिक DAO वर्गों में होने चाहिए।
• @Component - घटक स्टीरियोटाइप के साथ अपने अन्य घटकों (उदाहरण के लिए REST संसाधन कक्षाएं) को एनोटेट करें।
• @Autowired - स्प्रिंग ऑटो-वायर अन्य बीन्स को अपनी कक्षाओं में @Autowired एनोटेशन का उपयोग करने दें।

@Componentकिसी भी स्प्रिंग-प्रबंधित घटक के लिए एक सामान्य स्टीरियोटाइप है। @Repository, @Serviceऔर , क्रमशः, दृढ़ता, सेवा और प्रस्तुति परतों में, उदाहरण के लिए, अधिक विशिष्ट उपयोग के मामलों के @Controllerविशेषज्ञ @Componentहैं।

मूल रूप से यहाँ जवाब दिया ।

Answer 23

@Component, @Repository, @Controller & @Service एनोटेशन के बीच अंतर

@Component - जेनेरिक और आवेदन भर में इस्तेमाल किया जा सकता है।
@ सेवा - सेवा स्तर पर कक्षाओं को एनोटेट करें।
@ कंट्रोलर - प्रस्तुति परतों के स्तर पर एनोटेट कक्षाएं, मुख्य रूप से स्प्रिंग एमवीसी में उपयोग की जाती हैं।
@ रिपॉजिटरी - दृढ़ता परत पर एनोटेट कक्षाएं, जो डेटाबेस रिपॉजिटरी के रूप में कार्य करेगी।

@Controller= @Component (आंतरिक एनोटेशन) + प्रस्तुति परत सुविधाएँ
@Service= @Component (आंतरिक एनोटेशन) + सेवा परत सुविधाएँ
@Component= वास्तविक घटक (बीन्स)
@Repository= @Component (आंतरिक एनोटेशन) + डेटा परत सुविधाएँ (डोमेन बीन्स को संभालने के लिए उपयोग)

Answer 24

वसंत ढांचे में कुछ विशेष प्रकार के एनोटेशन प्रदान करते हैं, जिन्हें स्टीरियोटाइप एनोटेशन कहा जाता है। ये निम्नलिखित हैं: -

@RestController- Declare at controller level.
@Controller – Declare at controller level.
@Component – Declare at Bean/entity level.
@Repository – Declare at DAO level.
@Service – Declare at BO level.

ऊपर घोषित एनोटेशन विशेष हैं क्योंकि जब हम <context:component-scan>xxx-servlet.xml फ़ाइल में जोड़ते हैं, तो स्प्रिंग स्वचालित रूप से उन वर्गों की वस्तु का निर्माण करेगा, जिन्हें संदर्भ निर्माण / लोडिंग चरण के दौरान एनोटेशन के साथ एनोटेट किया गया है।

Answer 25

@Component, @ Repository, @ Service, @Controller:

@Componentघटकों द्वारा प्रबंधित के लिए एक सामान्य स्टीरियोटाइप है वसंत @Repository, @Serviceऔर @Controllerकर रहे हैं @Componentऔर अधिक विशिष्ट उपयोगों के लिए विशेषज्ञताओं:

• @Repository दृढ़ता के लिए
• @Service सेवाओं और लेनदेन के लिए
• @Controller MVC नियंत्रकों के लिए

का उपयोग क्यों करें @Repository, @Service,@Controller से अधिक@Component ? हम अपने घटक वर्गों को @Component के साथ चिह्नित कर सकते हैं, लेकिन अगर इसके बजाय हम उस विकल्प का उपयोग करते हैं जो अपेक्षित कार्यक्षमता के अनुकूल है। हमारी कक्षाएं प्रत्येक विशेष मामले में अपेक्षित कार्यक्षमता के लिए बेहतर अनुकूल हैं।

एक वर्ग के साथ टिप्पणी की गई @Repository है बेहतर अनुवाद और पठनीय त्रुटि है। डेटा तक पहुंचने वाले घटकों को लागू करने के लिए आदर्श (DataAccessObject या DAO)।

के साथ एक एनोटेट वर्ग @Controllerस्प्रिंग वेब MVC एप्लिकेशन में एक नियंत्रक भूमिका निभाता है

@Serviceव्यापार तर्क सेवाओं में एक एनोटेट वर्ग एक भूमिका निभाता है, उदाहरण के लिए DAO प्रबंधक (मुखौटा) और लेनदेन से निपटने के लिए मुखौटा पैटर्न

Answer 26

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

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

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

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

मैं अन्य उदाहरणों में नहीं जाऊंगा, लेकिन मैं जितना स्पष्ट रूप से बता सकता हूं: ये एनोटेशन पूरी तरह से अलग चीजें हैं और उनका उपयोग उचित रूप से किया जाना चाहिए, उनके इरादे के अनुसार। @Repositoryभंडारण रिपोजिटरी के लिए है और कोई अन्य एनोटेशन सही नहीं है। @Serviceसेवाओं के लिए है और कोई अन्य एनोटेशन सही नहीं है। @Componentऐसे घटकों के लिए है जो न तो रिपॉजिटरी हैं और न ही सेवाएं, और इसके स्थान पर इनमें से किसी एक का उपयोग करना भी गलत होगा। यह संकलित कर सकता है, यह आपके परीक्षणों को भी चला सकता है और पास कर सकता है, लेकिन यह गलत होगा और यदि आप ऐसा करने वाले थे तो मैं आपको (पेशेवर) कम सोचूंगा।

इसके पूरे वसंत के उदाहरण हैं (और सामान्य रूप से प्रोग्रामिंग)। @ControllerREST API लिखते समय आपको इसका उपयोग नहीं करना चाहिए , क्योंकि @RestControllerयह उपलब्ध है। वैध विकल्प @RequestMappingहोने पर आपको @GetMappingइसका उपयोग नहीं करना चाहिए । आदि आदि आदि आप चाहिए , जो सबसे सटीक सटीक चुना और सही भाषा आप कर सकते हैं अपने अपने पाठकों के लिए आशय संवाद करने के लिए, नहीं तो, आप अपने सिस्टम में जोखिम पेश कर रहे हैं, और जोखिम लागत है।

Comments

अच्छी तरह से और अच्छी बात कही!

— एंडी

Answer 27

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

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

@Service
public class Doer {
   // Your logic 
}

// To use it in another class, suppose in Controller 
@Controller
public class XController {
 // You have to inject it like this 
 @Autowired 
 private Doer doer;
}

सभी उसी तरह हैं जब आप उन्हें इंजेक्ट करते हैं, @ रिपॉजिटरी यह एक इंटरफ़ेस है जो रिपॉजिटरी पैटर्न रिपोजिटरी डिज़ाइन पैटर्न के लिए कार्यान्वयन को लागू करता है , आमतौर पर इसका उपयोग तब किया जाता है जब आप कुछ डेटा स्टोर या डेटाबेस के साथ काम कर रहे होते हैं, और आप पाएंगे कि, यह कई है डेटाबेस संचालन को संभालने के लिए आपके लिए तैयार कार्यान्वयन; यह CrudRepository , JpaRepository आदि हो सकता है ।

// For example
public interface DoerRepository implements JpaRepository<Long, XEntity> {}

अंत में @Component , स्प्रिंग में पंजीकृत बीन्स के लिए यह सामान्य रूप है, कि स्प्रिंग हमेशा @Component के साथ चिह्नित बीन की तलाश में है, तो @Service और @Repository दोनों ही @Component के विशेष मामले हैं, हालाँकि आम उपयोग का मामला है घटक के लिए है जब आप प्रत्यक्ष व्यावसायिक मामले को कवर करने के लिए विशुद्ध रूप से कुछ तकनीकी बना रहे हैं! जैसे तिथियों को प्रारूपित करना या विशेष अनुरोध क्रमबद्धता तंत्र वगैरह सौंपना।

Answer 28

@Component कॉन्फ़िगरेशन क्लास में @Bean एनोटेशन के रूप में कार्य करता है, स्प्रिंग संदर्भ में बीन रजिस्टर करता है। इसके अलावा यह @Service, @Repository और @Controller एनोटेशन के लिए जनक है।

@सर्विस , @Component एनोटेशन फैली हुई है और केवल नामकरण अंतर है।

@Repository - @Component एनोटेशन का विस्तार करता है और DataAccessException में सभी डेटाबेस अपवादों का अनुवाद करता है ।

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

Answer 29

@Component
@Controller
@Repository
@Service
@RestController

ये सभी स्टीरियो एनोटेशन हैं। ये हमारी कक्षाओं को आईओक कंटेनर में स्प्रिंग बीन्स के रूप में बनाने के लिए उपयोगी हैं,