2016-02-11 8 views
16

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

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

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

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

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

+0

क्या आपने हाइबरनेट-एनवर की कोशिश की है? –

+0

@XavierDury इस पोस्ट में स्पष्ट रूप से उल्लेख किया गया है कि हम परिवर्तनों का इतिहास रखने के लिए Envers का उपयोग करते हैं। जो मैं खोज रहा हूं वह यह जानने का एक लाइव तरीका है कि किसी विशेष इकाई में कौन से गुण बदल दिए गए थे, इसलिए हम उपयोगकर्ता को दिखा सकते हैं कि जब भी वे दिखाए जाते हैं तो इकाई के दो संस्करणों की तुलना करने के विशाल ओवरहेड के बिना। –

+1

@G_H सिर्फ मेरे जानने के लिए: क्या वास्तव में यह वही इकाई के दो संस्करणों को लोड करने के लिए खराब है, इसकी कीमतों की तुलना करने के लिए? मेरा मतलब है, क्या इन संस्थाओं के बारे में कुछ भी 'विशेष' है? यदि आप हमेशा अपनी दृढ़ता परत को जितना संभव हो उतना दुबला रखें, तो मुझे यह एक प्रदर्शन समस्या नहीं दिखाई दे रही है। – Bonifacio

उत्तर

1

शायद आप हाइबरनेट फ्लश इकाई ईवेंट श्रोता का उपयोग कर सकते हैं। गंदे गुणों की गणना फ्लश से पहले की जाती है। आप उन्हें अपने डेटाबेस में कहीं भी स्टोर कर सकते हैं।

sample code हाइबरनेट की गंदे गुण सुविधा का उपयोग करने के लिए जो आपको एक विचार दे सकता है।

+0

अंत में हमें वास्तव में इसकी आवश्यकता नहीं है (अभी तक) और बस उपयोगकर्ता को "काम करने वाली प्रति" के साथ प्रस्तुत करें। अगर किसी बिंदु पर जिसे बदला गया था, उसे स्पष्ट रूप से चिह्नित करने की आवश्यकता है, तो फ्लश श्रोता शायद सबसे अच्छा तरीका होगा, इसलिए मैं इसे स्वीकार करने के रूप में चिह्नित कर रहा हूं। मुझे कक्षा org.hibernate.EmptyListener गंदे गुणों को खोजने के लिए आधार प्रदान कर सकता है। आपके लिंक में 404'd है, तो शायद गंदे संपत्ति हैंडलिंग को अनुकूलित करने के तरीके के बारे में जानकारी प्रदान करने वाले कुछ SO प्रश्न/उत्तरों के साथ इसे प्रतिस्थापित करना बेहतर होगा। –