जेपीए इकाइयों का उपयोग करने में सबसे अच्छा अभ्यास क्या है?जेपीए POJO डेटा ऑब्जेक्ट के रूप में
चूंकि जेपीए इकाइयां सिर्फ पीओजेओ हैं, क्या यह ऑब्जेक्ट को सिस्टम के अन्य हिस्सों में डेटा ऑब्जेक्ट के रूप में उपयोग करने के लिए उचित माना जाता है या क्या मुझे उन्हें किसी अन्य डेटा ऑब्जेक्ट में परिवर्तित करना चाहिए?
क्या जेपीए से संबंधित सिस्टम के अन्य हिस्सों में जेपीए इकाई पीओजेओ का उपयोग करना स्वीकार्य है?
संस्थाएं अब अपने स्वयं के डेटा को परिवहन करने में सक्षम हैं, तो उन्हें किसी और चीज में बदलने में परेशानी क्यों है? दूसरे शब्दों में, मैं DTO an AntiPattern in EJB 3.0 से सहमत करते हैं:
EJB 3.0 से पहले EJB विशिष्टताओं में इकाई बीन्स के भारी वजन प्रकृति, Data Transfer Objects (डीटीओ) की तरह डिजाइन पैटर्न के उपयोग में हुई। डीटीओ हल्के वजन वाले ऑब्जेक्ट बन गए (जो कि इकाई बीन्स स्वयं को पहले स्थान पर होना चाहिए था), जो स्तरों में डेटा भेजने के लिए उपयोग किया जाता था। [...]
ईजेबी 3.0 spec एंटीटी बीन मॉडल सादा पुरानी जावा ऑब्जेक्ट (पीओजेओ) के समान बनाता है। इस नए पीओजेओ मॉडल के साथ, आपको अब प्रत्येक इकाई या संस्थाओं के समूह के लिए डीटीओ बनाने की आवश्यकता नहीं होगी। यदि आप स्तर पर ईजेबी 3.0 इकाइयों को भेजना चाहते हैं तो उन्हें
java.io.Serialiazableलागू करें।
यह "अन्य भागों" के साथ आपका क्या मतलब है इस पर निर्भर करता है। चूंकि आपकी जेपीए इकाइयों को किसी भी तरह से आपके सिस्टम से संबंधित होना चाहिए, क्योंकि वे पहले से ही वहां क्यों नहीं हैं। महत्वपूर्ण बात यह है कि आप दो अलग-अलग चिंताओं के लिए एक ही कक्षा का उपयोग नहीं करते हैं (जो तब इमो या तो खराब डिजाइन का संकेत है या सिर्फ एक बड़ी प्रणाली है)। बाकी सब कुछ शायद आपके अलग-अलग पीओजेओ परेशानी के बीच एक अंतहीन मैपिंग में समाप्त हो जाएगा।
उदाहरण के लिए एक उपयोगकर्ता लॉगिन। वेब आधारित लॉगिन के लिए एक अलग UserLoginForm बीन बनाने के लिए यह सामान्य वर्बोज़ जावा अभ्यास हो सकता है लेकिन इस पर विचार करें:
आपके पास पहले से ही आपके उपयोगकर्ता जेपीए इकाइयां (और इसलिए उपयोगकर्ता POJO) डेटाबेस में हैं (इसमें उपयोगकर्ता नाम, पासवर्ड है हैश, पता और शायद अन्य सामान संग्रहित)। आप वेब फॉर्म से अपने लॉगिन अनुरोध में बिल्कुल वही ऑब्जेक्ट का उपयोग कर सकते हैं (स्प्रिंग जैसे कुछ फ्रेमवर्क इसे तुरंत मैप करेंगे)। एक खाली उपयोगकर्ता ऑब्जेक्ट बनाएं, उपयोगकर्ता नाम और हैश पासवर्ड सेट करें और उदाहरण के लिए जेपीए क्वेरी बनाएं। यदि वह क्वेरी बिल्कुल एक परिणाम देता है तो लॉगिन मान्य है और आप सत्र में लोड किए गए उपयोगकर्ता ऑब्जेक्ट को स्टोर कर सकते हैं।
यह एक अच्छा सवाल है।
शेष सिस्टम में जेपीए इकाई वर्गों को उजागर करके आप दृढ़ता तंत्र और डीबी मैपिंग पर ऑब्जेक्ट का पर्दाफाश करते हैं। आप इन वस्तुओं को कैसे क्रोधित और प्रबंधित करते हैं, इस पर नियंत्रण खो देते हैं। दृढ़ता encapsulation तोड़कर, एक परिवर्तन के बाकी सिस्टम पर एक लहर प्रभाव हो सकता है।
सिस्टम दृढ़ता में भविष्य में परिवर्तन असंभव, अजीब, सीमित और/या जोखिम भरा हो सकता है। उदाहरण: आपको प्रदर्शन और/या स्केलेबिलिटी के लिए अनुकूलित करने की आवश्यकता हो सकती है। इसके लिए कैशिंग, डीबी स्कीमा परिवर्तन, गैर आरडीबीएमएस उपयोग, एकाधिक डेटाबेस की आवश्यकता हो सकती है। Encapsulation भी भविष्य डीबी schemas के प्रवासन को कम करने में मदद करता है।
तो व्यापार बंद है:
यदि पहला सिस्टम व्यापक परिवर्तन स्वीकार्य नहीं है तो पहला विकल्प आवश्यक हो सकता है - उदा। तीसरे पक्ष आपके डेटा तक पहुंच रहे हैं। या शायद आपने 3 परत आर्किटेक्चर पर निर्णय लिया है: जीयूआई, बिजनेस लॉजिक, दृढ़ता।
दूसरा विकल्प ठीक है यदि आपके पास एक चुस्त विकास प्रक्रिया है और पूरे सिस्टम पर नियंत्रण है और इस तथ्य को स्वीकार करते हैं कि सिस्टम के व्यापक परिवर्तन लाइन के नीचे आवश्यक हो सकते हैं।
आपको जवाब के साथ श्रेय देना क्योंकि आप एंटीपाटर पर दिलचस्प दस्तावेज से जुड़े हुए हैं। – Tazzy531