हाइबरनेट: क्लाइंट-सर्वर एप्लिकेशन को विकसित करने में आलसी आरंभीकरण का उपयोग करना

हाइबरनेट का उपयोग करके विकसित किए गए एप्लिकेशन के डोमेन को डिज़ाइन करते समय, डेवलपर को एक विकल्प बनाने की आवश्यकता होती है: क्या संबंधित डोमेन के संग्रह के समान डोमेन गुणों को तुरंत प्रारंभ करना है (FetchType = EAGER) या केवल उन्हें एक्सेस करते समय ऐसा करें (FetchType = LAZY)। वास्तव में, मामले में जब विषय क्षेत्र में वस्तुओं के बीच संबंधों की किसी भी प्रकार की जटिल संरचना होती है, तो विकल्प पहले ही बना दिया गया है - एक वस्तु की खातिर आधा डेटाबेस लोड करने के लिए, जैसा कि FetchType = EAGER के साथ होगा, कम से कम, अनुचित कहने के लिए। इसलिए, संग्रह के मामले में आलसी आरंभीकरण संबंधित वस्तुओं को प्रारंभिक करने के लिए सबसे पसंदीदा रणनीति है।



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





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



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



कल्पना करें कि अनुप्रयोग के सर्वर पक्ष में 3 परतें हैं:

• सेवा परत (ऑब्जेक्ट जो क्लाइंट के साथ काम करता है);
• व्यावसायिक तर्क की एक परत (ऐसी वस्तुएं जो अनुप्रयोग के व्यावसायिक तर्क को लागू करती हैं);
• दृढ़ता परत (हाइबरनेट, डोमेन)।

डोमेन कक्षाएं स्वयं सर्वर और क्लाइंट दोनों के लिए उपलब्ध हैं (जो सामान्य रूप से, तार्किक है)।



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



सवाल केवल यह है कि इस "डीपोक्सिंग" को कैसे पूरा किया जाए। सिद्धांत रूप में, यह हाइबरनेट का उपयोग करके किया जा सकता है :

public static <T> T initializeAndUnproxy(T entity) {

if (entity == null ) {

throw new

NullPointerException( "Entity passed for initialization is null" );

}



Hibernate.initialize(entity);

if (entity instanceof HibernateProxy) {

entity = (T) ((HibernateProxy) entity).getHibernateLazyInitializer()

.getImplementation();

}

return entity;

}



* This source code was highlighted with Source Code Highlighter .

ऐसा दृष्टिकोण किसी दिए गए ऑब्जेक्ट के सभी संग्रहों को आरंभ करता है और इसे प्रॉक्सी से "प्राप्त" करता है। हालाँकि, इसमें कई कमियाँ हैं: एक पंक्ति में सभी संग्रह आरंभीकृत हैं और केवल मूल वस्तु को ही हटा दिया गया है (कम से कम क्योंकि यह स्पष्ट नहीं है कि आपको डीपो को चालू करते समय कनेक्शन के ऑब्जेक्ट के ग्राफ को नीचे जाने की कितनी गहरी आवश्यकता है)।



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



मैं यह नहीं कहता कि यह दृष्टिकोण इष्टतम है और / या एकमात्र सही है। यदि आपके पास समस्या को अलग तरीके से हल करने के बारे में कोई सुझाव है, तो मुझे उन्हें सुनने में खुशी होगी।