यह अच्छा है कि स्प्रिंगबूट जैसा फ्रेमवर्क आपके लिए बहुत कुछ कर सकता है।

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

आप एक साधारण REST नियंत्रक वर्ग लिखते हैं और आपके पास एक REST API चल रहा है, है ना?

अरे, लेकिन आप डीटीओ लिखना भूल गए! लेकिन वास्तव में आपको इसकी आवश्यकता क्यों है जब आपका ऐप इसके बिना काम कर सकता है?

निश्चित रूप से कुछ सामान्य कारण हैं:

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

लेकिन अन्य अजीब चीजें भी हो सकती हैं। मैं आपको अपने अनुभव के आधार पर एक अजीब उदाहरण दिखाऊंगा।

इस GitHub रेपो में एक सरल एप्लिकेशन शामिल है जो DTO के बिना काम करता है। एक उपयोगकर्ता इकाई है, प्रत्येक उपयोगकर्ता के पास एकाधिक लेनदेन हो सकते हैं। हमारे पास रिपॉजिटरी और रेस्टकंट्रोलर के बीच एक सर्विस बीन भी है, जो संभावित डेटाबेस एक्सेस अपवादों को पकड़ता है।

चूंकि हम एक उत्पादन-तैयार एप्लिकेशन बनाना चाहते हैं, हम नहीं चाहते कि हाइबरनेट डीडीएल उत्पन्न करे। इसके बजाय, हमारे पास एक schema.sql है जो तालिकाएँ बनाता है (बाद में हम फ्लाईवे या लिक्विबेस पर स्विच कर सकते हैं)। हमारे सरल उदाहरण के लिए, हमारे पास एक data.sql भी है ताकि हमारी तालिकाएँ खाली न रहें।

जब हम एप्लिकेशन चलाते हैं और एपीआई एंडपॉइंट को http://localhost:8080/users पर कॉल करते हैं, तो हमें अपेक्षित JSON मिलता है जिसमें उपयोगकर्ता और उनके लेनदेन शामिल होते हैं।

अब लेनदेन वर्ग में //!!
चिह्नित कोड की दो पंक्तियों पर ध्यान दें

@JsonIgnore //!!

पहली गंध यह है कि ट्रांजेक्शन क्लास में हमें उपयोगकर्ता संदर्भ में @JsonIgnore एनोटेशन जोड़ना था। उस एनोटेशन के बिना JSON क्रमबद्धता अनंत रिकर्सन के कारण क्रैश हो जाती है।

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

निजी स्ट्रिंग विवरण;//!!

बेशक, अब एपीआई कॉल विफल हो गई है। लेकिन त्रुटि प्रबंधन को देखो! UserService के अंदर कैच क्लॉज़ अपेक्षानुसार काम नहीं करता है। इसके बजाय हम लॉग में एक अजीब स्टैक ट्रेस देख सकते हैं:
GlobalExceptionHandler : अनपेक्षित त्रुटि org.springframework.http.converter.HttpMessageNotWritableException: JSON नहीं लिख सका:

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

क्या होता है, UserService वर्ग (UserRepository के माध्यम से) केवल USERS डेटाबेस तालिका पर सवाल उठाता है। डिफ़ॉल्ट हाइबरनेट आलसी लोडिंग के कारण लेनदेन इकाइयाँ परिणाम का हिस्सा नहीं हैं। केवल जब जैक्सन डिसेरिएलाइज़र उपयोगकर्ता उदाहरण से JSON बनाने का प्रयास करता है, तो यह अपनी getTransactions विधि को लागू करता है जो हाइबरनेट को लेनदेन इकाइयों को लाने में सक्षम बनाता है।

यही कारण है कि हमें JSON और SQL सामग्री को मिलाकर एक अजीब स्टैकट्रेस मिलता है। अपवाद को GlobalExceptionHandler ने पकड़ लिया है और उसे नहीं पता कि इसके साथ क्या करना है, यही कारण है कि लॉग संदेश "अप्रत्याशित त्रुटि" है।

मुझे आशा है कि यह छोटा सा अभ्यास आपको अधिक गहराई से समझ देगा कि आपके एप्लिकेशन की विभिन्न परतों को मिश्रण करने की अनुमति देना कितना खतरनाक है। आपके एप्लिकेशन के केवल "धूप वाले दिन" परिदृश्यों को देखने से, जबकि यह अभी भी छोटा है, कुछ डेवलपर्स गलत काम करना जारी रख सकते हैं, जब तक कि बहुत देर न हो जाए।

आपको अपने डीटीओ और अपने एप्लिकेशन की अन्य परतों के बीच फ़ील्ड को मैप करते हुए बॉयलरप्लेट कोड लिखने की ज़रूरत नहीं है। मैपस्ट्रक्चर आपके लिए यह कर सकता है।