द 10 मोस्ट कॉमन स्प्रिंग फ्रेमवर्क एरर्स

नमस्कार, हेब्र! मैं आपको टोनी कुकुरिन के लेख "टॉप 10 मोस्ट कॉमन स्प्रिंग फ्रेमवर्क मिस्टेक्स" का अनुवाद प्रस्तुत करता हूं।

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

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

आम गलती # 1: बहुत नीचे उतरो

हम इस सामान्य गलती का सामना करते हैं क्योंकि "यहां आविष्कार नहीं किया गया है" सिंड्रोम सॉफ्टवेयर विकास की दुनिया में काफी आम है। लक्षणों में नियमित रूप से उपयोग किए गए कोड के टुकड़े को फिर से लिखना शामिल है, और कई डेवलपर्स इससे पीड़ित लगते हैं।

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

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

@Getter @Setter @NoArgsConstructor public class Bean implements Serializable { int firstBeanProperty; String secondBeanProperty; } 

जैसा कि आप कल्पना कर सकते हैं, उपरोक्त कोड में संकलित है:

 public class Bean implements Serializable { private int firstBeanProperty; private String secondBeanProperty; public int getFirstBeanProperty() { return this.firstBeanProperty; } public String getSecondBeanProperty() { return this.secondBeanProperty; } public void setFirstBeanProperty(int firstBeanProperty) { this.firstBeanProperty = firstBeanProperty; } public void setSecondBeanProperty(String secondBeanProperty) { this.secondBeanProperty = secondBeanProperty; } public Bean() { } } 

हालांकि, ध्यान दें कि यदि आप अपने आईडीई के साथ लोम्बोक का उपयोग करने का इरादा रखते हैं, तो आपको सबसे अधिक संभावना प्लगइन को स्थापित करना होगा। IntelliJ IDEA के लिए प्लगइन संस्करण यहां पाया जा सकता है ।

आम गलती # 2: आंतरिक सामग्री लीक

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

 @Entity @NoArgsConstructor @Getter public class TopTalentEntity { @Id @GeneratedValue private Integer id; @Column private String name; public TopTalentEntity(String name) { this.name = name; } } 

मान लीजिए कि एक समापन बिंदु है जिसे TopTalentEntity डेटा तक पहुंचने की आवश्यकता है। कोई फर्क नहीं पड़ता कि TopTalentEntity इंस्टेंस को वापस करने के लिए कितना आकर्षक है, एपीआई एंडपॉइंट पर TopTalentEntity डेटा प्रदर्शित करने के लिए एक नया वर्ग बनाने के लिए एक अधिक लचीला समाधान होगा:

 @AllArgsConstructor @NoArgsConstructor @Getter public class TopTalentData { private String name; } 

इस प्रकार, डेटाबेस बैकएंड में परिवर्तन करने से सर्विस लेयर में किसी भी अतिरिक्त बदलाव की आवश्यकता नहीं होगी। इस बारे में सोचें कि यदि आप डेटाबेस में उपयोगकर्ता पासवर्ड हैश को स्टोर करने के लिए TopTalentEntity में पासवर्ड फ़ील्ड जोड़ते हैं तो क्या होगा - TopTalentData जैसे कनेक्टर के बिना, यदि आप सेवा को बदलना भूल जाते हैं, तो दृश्यपटल गलती से कुछ अवांछनीय गुप्त जानकारी प्रदर्शित करेगा!

सामान्य गलती # 3: कर्तव्यों के अलगाव की कमी

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

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

 @RestController public class TopTalentController { private final TopTalentRepository topTalentRepository; @RequestMapping("/toptal/get") public List<TopTalentData> getTopTalent() { return topTalentRepository.findAll() .stream() .map(this::entityToData) .collect(Collectors.toList()); } private TopTalentData entityToData(TopTalentEntity topTalentEntity) { return new TopTalentData(topTalentEntity.getName()); } } 

सबसे पहले, यह ध्यान देने योग्य नहीं है कि कोड के इस टुकड़े के साथ कुछ गलत है। यह एक TopTalentData सूची प्रदान करता है जो TopTalentEntity उदाहरणों से पुनर्प्राप्त की जाती है। हालांकि, अगर आप बारीकी से देखें, तो हम देखेंगे कि वास्तव में TopTalentController कुछ चीजें यहां करता है। अर्थात्: यह एक विशिष्ट समापन बिंदु के लिए नक्शे का अनुरोध करता है, रिपॉजिटरी से डेटा निकालता है, और TopTalentRepository से प्राप्त संस्थाओं को दूसरे प्रारूप में परिवर्तित करता है। एक "क्लीनर" समाधान इन जिम्मेदारियों को अपनी कक्षाओं में विभाजित करना होगा। यह कुछ इस तरह दिख सकता है:

 @RestController @RequestMapping("/toptal") @AllArgsConstructor public class TopTalentController { private final TopTalentService topTalentService; @RequestMapping("/get") public List<TopTalentData> getTopTalent() { return topTalentService.getTopTalent(); } } @AllArgsConstructor @Service public class TopTalentService { private final TopTalentRepository topTalentRepository; private final TopTalentEntityConverter topTalentEntityConverter; public List<TopTalentData> getTopTalent() { return topTalentRepository.findAll() .stream() .map(topTalentEntityConverter::toResponse) .collect(Collectors.toList()); } } @Component public class TopTalentEntityConverter { public TopTalentData toResponse(TopTalentEntity topTalentEntity) { return new TopTalentData(topTalentEntity.getName()); } } 

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

आम गलती # 4: असंगति और गरीब त्रुटि से निपटने

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

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

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

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

 @Value public class ErrorResponse { private Integer errorCode; private String errorMessage; } 

कुछ ऐसा ही आमतौर पर सबसे लोकप्रिय एपीआई में पाया जाता है और आमतौर पर यह अच्छी तरह से काम करता है, क्योंकि यह आसानी से और व्यवस्थित रूप से प्रलेखित किया जा सकता है। आप @ExceptionHandler एनोटेशन (आम गलती # 6 में एनोटेशन का एक उदाहरण दिया गया है) के साथ विधि प्रदान करके इस प्रारूप में अपवादों का अनुवाद कर सकते हैं।

कॉमन मिस्टेक # 5: गलत मल्टीथ्रेडिंग

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

आदर्श रूप से, निश्चित रूप से, आप मल्टीथ्रेडिंग बग्स से पूरी तरह से बचना चाहेंगे। फिर, इसके लिए कोई एकल दृष्टिकोण नहीं है, लेकिन यहां डिबगिंग और मल्टीथ्रेडिंग त्रुटियों को रोकने के लिए कुछ व्यावहारिक विचार दिए गए हैं:

ग्लोबल स्टेटस से बचें

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

उत्परिवर्तन से बचें

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

महत्वपूर्ण डेटा लॉग करें

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

मौजूदा कार्यान्वयन का पुन: उपयोग करें

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

सामान्य गलती # 6: एनोटेशन-आधारित सत्यापन का उपयोग नहीं करना

आइए कल्पना करें कि ऊपर वर्णित हमारी TopTalent सेवा, नए सुपर टैलेंट को जोड़ने के लिए एक समापन बिंदु की आवश्यकता है। इसके अलावा, मान लीजिए कि वास्तव में अच्छे कारण के लिए, प्रत्येक नए नाम को ठीक 10 वर्ण लंबा होना चाहिए। ऐसा करने का एक तरीका इस प्रकार हो सकता है:

 @RequestMapping("/put") public void addTopTalent(@RequestBody TopTalentData topTalentData) { boolean nameNonExistentOrHasInvalidLength = Optional.ofNullable(topTalentData) .map(TopTalentData::getName) .map(name -> name.length() == 10) .orElse(true); if (nameNonExistentOrInvalidLength) { // throw some exception } topTalentService.addTopTalent(topTalentData); } 

हालाँकि, ऊपर (खराब डिज़ाइन किए जाने के अलावा) वास्तव में एक "साफ" समाधान नहीं है। हम एक से अधिक प्रकार की वैधता की जांच करते हैं (अर्थात, TopTalentData null नहीं है, और वह TopTalentData.name शून्य नहीं है, और वह TopTalentData.name 10 वर्ण लंबा है), और डेटा अमान्य होने पर अपवाद भी फेंकता है।

यह स्प्रिंग के साथ हाइबरनेट सत्यापनकर्ता का उपयोग करके बहुत अधिक सफाई से किया जा सकता है। सबसे पहले, हम सत्यापन का समर्थन करने के लिए AddTopTalent विधि को फिर से लिखते हैं:

 @RequestMapping("/put") public void addTopTalent(@Valid @NotNull @RequestBody TopTalentData topTalentData) { topTalentService.addTopTalent(topTalentData); } @ExceptionHandler @ResponseStatus(HttpStatus.BAD_REQUEST) public ErrorResponse handleInvalidTopTalentDataException(MethodArgumentNotValidException methodArgumentNotValidException) { // handle validation exception } 

इसके अलावा, हमें इंगित करना चाहिए कि हम TopTalentData वर्ग में कौन सी संपत्ति की जांच करना चाहते हैं:

 public class TopTalentData { @Length(min = 10, max = 10) @NotNull private String name; } 

वसंत अब अनुरोध को रोक देगा और विधि को कॉल करने से पहले इसे सत्यापित करेगा - अतिरिक्त मैनुअल परीक्षणों का उपयोग करने की कोई आवश्यकता नहीं है।

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

 @Target({ElementType.METHOD, ElementType.FIELD, ElementType.PARAMETER}) @Retention(RetentionPolicy.RUNTIME) @Documented @Constraint(validatedBy = { MyAnnotationValidator.class }) public @interface MyAnnotation { String message() default "String length does not match expected"; Class<?>[] groups() default {}; Class<? extends Payload>[] payload() default {}; int value(); } @Component public class MyAnnotationValidator implements ConstraintValidator<MyAnnotation, String> { private int expectedLength; @Override public void initialize(MyAnnotation myAnnotation) { this.expectedLength = myAnnotation.value(); } @Override public boolean isValid(String s, ConstraintValidatorContext constraintValidatorContext) { return s == null || s.length() == this.expectedLength; } } 

ध्यान दें कि इन मामलों में, कर्तव्यों के पृथक्करण के लिए सर्वोत्तम प्रथाओं के लिए आवश्यक है कि आप एक संपत्ति को वैध के रूप में चिह्नित करें यदि यह शून्य है (isValid विधि में अशक्त), और तब NotNull एनोटेशन का उपयोग करें यदि यह संपत्ति के लिए एक अतिरिक्त आवश्यकता है:

 public class TopTalentData { @MyAnnotation(value = 10) @NotNull private String name; } 

कॉमन मिस्टेक # 7: एक्सएमएल कॉन्फ़िगरेशन का उपयोग करना (अभी भी)

हालांकि XML स्प्रिंग के पिछले संस्करणों के लिए आवश्यक था, वर्तमान में अधिकांश कॉन्फ़िगरेशन विशेष रूप से जावा कोड / एनोटेशन के साथ किया जा सकता है। XML कॉन्फ़िगरेशन केवल एक अतिरिक्त और अनावश्यक बॉयलरप्लेट का प्रतिनिधित्व करते हैं।
यह आलेख (और इसके साथ GitHub रिपॉजिटरी) स्प्रिंग को कॉन्फ़िगर करने के लिए एनोटेशन का उपयोग करता है और स्प्रिंग जानता है कि किन बीन्स को कनेक्ट करना चाहिए क्योंकि रूट पैकेज को @SpringBootApplication कंपाउंड एनोटेशन का उपयोग करके एनोटेट किया गया था, उदाहरण के लिए:

 @SpringBootApplication public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } } 

यह समग्र एनोटेशन (आप स्प्रिंग डॉक्यूमेंट में इसके बारे में अधिक जान सकते हैं) बस स्प्रिंग को संकेत देता है कि किन बीन्स को निकालने के लिए पैकेज को स्कैन किया जाना चाहिए। हमारे विशेष मामले में, इसका मतलब है कि निम्न वर्ग सेम को जोड़ने के लिए उपयोग किया जाएगा, जो शीर्ष-स्तरीय पैकेज (co.kukurin) से शुरू होता है:

• @Component (TopTalentConverter, MyAnnotationValidator) @RestController (TopTalentController) @Repository (TopTalentRepository) @Service (TopTalentService)
• @Component (TopTalentConverter, MyAnnotationValidator) @RestController (TopTalentController) @Repository (TopTalentRepository) @Service (TopTalentService)
• @Component (TopTalentConverter, MyAnnotationValidator) @RestController (TopTalentController) @Repository (TopTalentRepository) @Service (TopTalentService)
• @Component (TopTalentConverter, MyAnnotationValidator) @RestController (TopTalentController) @Repository (TopTalentRepository) @Service (TopTalentService)

अगर हमारे पास @Configuration के साथ कोई अतिरिक्त कक्षाएं एनोटेट की गई हैं, तो उन्हें जावा कॉन्फ़िगरेशन के लिए भी जांचा जाएगा।

सामान्य गलती नंबर 8: प्रोफाइल के बारे में भूल जाओ

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

स्थानीय विकास के लिए इन-मेमोरी डेटाबेस और PROM में MySQL डेटाबेस का उपयोग करते समय मामले पर विचार करें। संक्षेप में, इसका मतलब यह होगा कि आप उनमें से प्रत्येक का उपयोग करने के लिए अलग-अलग URL और (उम्मीद है) अलग-अलग क्रेडेंशियल्स का उपयोग करेंगे। आइए देखें कि यह दो अलग-अलग कॉन्फ़िगरेशन फ़ाइलों के साथ कैसे किया जा सकता है:

फ़ाइल आवेदन

 # set default profile to 'dev' spring.profiles.active: dev # production database details spring.datasource.url: 'jdbc:mysql://localhost:3306/toptal' spring.datasource.username: root spring.datasource.password: 

फ़ाइल आवेदन- DEV.YAML

 spring.datasource.url: 'jdbc:h2:mem:' spring.datasource.platform: h2 

जाहिरा तौर पर, आप कोड के साथ गड़बड़ करते समय अपने औद्योगिक डेटाबेस पर गलती से कोई कार्रवाई नहीं करना चाहते हैं, इसलिए यह डिफ़ॉल्ट प्रोफ़ाइल को देव में सेट करने के लिए समझ में आता है। फिर सर्वर पर, आप JVM के लिए -Dspring.profiles.active = ठेस पैरामीटर निर्दिष्ट करके मैन्युअल रूप से कॉन्फ़िगरेशन प्रोफ़ाइल को ओवरराइड कर सकते हैं। इसके अलावा, आप वांछित डिफ़ॉल्ट प्रोफ़ाइल में ओएस पर्यावरण चर भी सेट कर सकते हैं।

आम गलती # 9: निर्भरता इंजेक्शन स्वीकार करने में असमर्थता

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

 public class TopTalentController { private final TopTalentService topTalentService; public TopTalentController() { this.topTalentService = new TopTalentService(); } } 

हम वसंत को हमारे लिए बाध्यकारी करते हैं:

 public class TopTalentController { private final TopTalentService topTalentService; public TopTalentController(TopTalentService topTalentService) { this.topTalentService = topTalentService; } } 

Google टॉक की मिसको हेवरी निर्भरता इंजेक्शन के लिए "कारणों" के बारे में विस्तार से बताती है , इसलिए आइए देखें कि यह कैसे व्यवहार में उपयोग किया जाता है। जिम्मेदारियों के विभाजन में (कॉमन मिस्टेक्स # 3), हमने सेवा और नियंत्रक कक्षाएं बनाईं। मान लीजिए कि हम इस धारणा के तहत एक नियंत्रक का परीक्षण करना चाहते हैं कि TopTalentService सही व्यवहार कर रहा है। हम वास्तविक सेवा कार्यान्वयन के बजाय एक मॉक ऑब्जेक्ट डाल सकते हैं, एक अलग कॉन्फ़िगरेशन क्लास प्रदान कर सकते हैं:

 @Configuration public class SampleUnitTestConfig { @Bean public TopTalentService topTalentService() { TopTalentService topTalentService = Mockito.mock(TopTalentService.class); Mockito.when(topTalentService.getTopTalent()).thenReturn( Stream.of("Mary", "Joel") .map(TopTalentData::new).collect(Collectors.toList())); return topTalentService; } } 

फिर हम स्प्रिंग को नमूना प्रदाता के रूप में नमूना प्रदाता के रूप में उपयोग करने के लिए मॉक ऑब्जेक्ट को एम्बेड कर सकते हैं।

 @ContextConfiguration(classes = { SampleUnitTestConfig.class }) 

फिर यह हमें यूनिट टेस्ट में कस्टम बीन को एम्बेड करने के लिए संदर्भ कॉन्फ़िगरेशन का उपयोग करने की अनुमति देगा।

सामान्य गलती # 10: परीक्षण या गलत परीक्षण की कमी

इस तथ्य के बावजूद कि इकाई परीक्षण का विचार लंबे समय से हमारे साथ है, कई डेवलपर्स ऐसा करने के लिए "भूल" लगते हैं (विशेषकर यदि यह आवश्यक नहीं है), या बस इसे बाद के लिए छोड़ दें। जाहिर है, यह अवांछनीय है, क्योंकि परीक्षणों को न केवल आपके कोड की शुद्धता को सत्यापित करना चाहिए, बल्कि यह भी प्रलेखन के रूप में कार्य करना चाहिए कि आवेदन को विभिन्न स्थितियों में कैसे व्यवहार करना चाहिए।

वेब सेवाओं का परीक्षण करते समय, आप शायद ही कभी "स्वच्छ" इकाई परीक्षण करते हैं, क्योंकि HTTP के माध्यम से बातचीत के लिए आमतौर पर डिस्पैचर सेर्वलेट स्प्रिंग को कॉल करने की आवश्यकता होती है और यह देखने पर कि वास्तविक HttpServletRequest प्राप्त होने पर क्या होता है (जो इसे एक एकीकरण परीक्षण बनाता है, के साथ सत्यापन, क्रमांकन आदि का उपयोग करना)। REST एश्योर्ड - MockMVC के शीर्ष पर REST सेवाओं का आसानी से परीक्षण करने के लिए जावा डीएसएल एक बहुत ही सुंदर समाधान साबित हुआ है। निर्भरता इंजेक्शन के साथ निम्नलिखित कोड टुकड़ा पर विचार करें:

 @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(classes = { Application.class, SampleUnitTestConfig.class }) public class RestAssuredTestDemonstration { @Autowired private TopTalentController topTalentController; @Test public void shouldGetMaryAndJoel() throws Exception { // given MockMvcRequestSpecification givenRestAssuredSpecification = RestAssuredMockMvc.given() .standaloneSetup(topTalentController); // when MockMvcResponse response = givenRestAssuredSpecification.when().get("/toptal/get"); // then response.then().statusCode(200); response.then().body("name", hasItems("Mary", "Joel")); } } 

SampleUnitTestConfig TopTalentController में TopTalentService मॉक क्रियान्वयन को सक्षम करता है, जबकि अन्य सभी वर्ग अनुप्रयोग वर्ग के पैकेज में जड़ों वाले स्कैनिंग पैकेट द्वारा प्राप्त मानक कॉन्फ़िगरेशन का उपयोग करके जुड़े हुए हैं। RestAssuredMockMvc का उपयोग केवल हल्के वातावरण बनाने और / toptal / समापन बिंदु के लिए GET अनुरोध भेजने के लिए किया जाता है।

स्प्रिंग मास्टर बनें

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

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

टैग
जावा स्प्रिंगफ़्रेमवर्क

टिप्पणियाँ

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

टिमोथी शिमंडल के लिए
पूरी तरह से सहमत हूँ। ऐसा लगता है कि कोड की एक अनावश्यक अतिरिक्त परत जोड़ दी गई है, मुझे लगता है कि @JsonIgnore खेतों को अनदेखा करने में मदद करेगा (यद्यपि डिफ़ॉल्ट रिपॉजिटरी डिटेक्शन रणनीतियों में खामियों के साथ), लेकिन कुल मिलाकर यह एक महान ब्लॉग पोस्ट है। गर्व करने के लिए ठोकर ...

Arokiadoss Asirvatham
यार, एक और सामान्य शुरुआत की गलती: 1) चक्रीय निर्भरता, और 2) बुनियादी सिंगलटन क्लास डिक्लेरेशन सिद्धांतों के साथ गैर-अनुपालन, जैसे कि सिंगलटन स्कोल के साथ बीन्स में एक आवृत्ति चर का उपयोग करना।

Hlodowig
नंबर 8 के बारे में, मेरा मानना ​​है कि प्रोफाइल के दृष्टिकोण बहुत असंतोषजनक हैं। आइए देखें:

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

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

महान लेख टोनी, अच्छा काम जारी रखें!

अनुवाद पूरा हुआ: tele.gg/middle_java