java-object-merger - वस्तुओं के सिर्फ एक मैपर से अधिक

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

युपीडी। केंद्रीय मावेन भंडार में पोस्ट किया गया

<dependency> <groupId>net.sf.brunneng.jom</groupId> <artifactId>java-object-merger</artifactId> <version>0.8.5.1</version> </dependency> 

UPD2 । संस्करण 0.8.4

ऑब्जेक्ट मैपर्स किसके लिए हैं?

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

यदि आप समस्या को हल करते हैं, तो आपको कुछ इस तरह का "डंब" कोड मिलता है:

 … employeeVO.setPositionName(employee.getPositionName()); employeeVO.setPerson(new PersonVO()); PersionVO personVO = employeeVO.getPerson(); PersonDTD person = employee.getPerson(); personVO.setFirstName(person.getFirstName()); personVO.setMiddleName(person.getMiddleName()); personVO.setLastName(person.getLastName()); ... 

क्या वह परिचित है? :) अगर हाँ, तो मैं आपको खुश कर सकता हूँ। इस समस्या के लिए पहले से ही एक समाधान है।

वस्तुओं का मैपर

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

क्या खराब है डोजर

1. एनोटेशन के माध्यम से खराब कॉन्फ़िगरेशन का समर्थन (केवल @Mapping )।
2. कई क्षेत्रों से एक के लिए मैप करना असंभव है (उदाहरण के लिए, नाम, उपनाम और संरक्षक से पूरा नाम इकट्ठा करने के लिए)।
3. सामान्य गुण मैपिंग के साथ समस्या। यदि पैरेंट एब्स्ट्रैक्ट क्लास में एक ऐसा गैटर होता है जो जेनेरिक टाइप T लौटाता है, जहाँ , T , T. IEntity, , ..
   संपत्ति वर्गों को आंतरिक डॉसर कैश में तार के रूप में संग्रहीत किया जाता है, और वर्ग प्राप्त करने के लिए एक विशेष लोडर वर्ग का उपयोग किया जाता है। जब ऑस्कर एक बंडल में होता है और दूसरे में वांछित बीन क्लास पहले से सुलभ नहीं होता है, तो ओस्गी वातावरण में इसके साथ समस्याएं उत्पन्न होती हैं। हमने समस्या को काबू कर लिया, भले ही एक मानक तरीके से - वांछित लोडर वर्ग को फिसलने से, कार्यान्वयन खुद: कक्षा को एक स्ट्रिंग के रूप में संग्रहीत करना अजीब लगता है। शायद यह क्रम में है कि हम परमिट जनरल स्पेस स्मारक न बनाएं। लेकिन फिर भी बहुत स्पष्ट नहीं है।
   अगर कोई चीज़ अचानक से नहीं बनती है, तो उसका पता लगाना बहुत मुश्किल है। यदि आप डॉसर को डिबेट करते हैं, तो आप समझेंगे कि क्यों। वहाँ किसी तरह का है ... OOP पैटर्न का सिर्फ एक पागल ढेर - सब कुछ भ्रमित है और स्पष्ट नहीं है। हालाँकि, यह केवल मेरे स्वाद के लिए है।
   
   

   मैपर में क्या गुण होना चाहिए?

   
   
   1. एनोटेशन के माध्यम से व्यापक कॉन्फ़िगरेशन समर्थन।
   2. पूर्ण सामान्य समर्थन।
   3. एक साफ, समझने योग्य कोड जिसे कोई भी मस्तिष्क को तोड़े बिना जोखिम में डाल सकता है।
   4. डिफ़ॉल्ट रूप से, किसी भी अतिरिक्त सेटिंग्स के बिना, इसे उस तरीके से मैप करना चाहिए जो डेवलपर सबसे अधिक उम्मीद करेगा।
   5. यह ठीक से संभव होना चाहिए (डोजर से बदतर नहीं)।
   
   
   

   विलय और मैपर क्यों नहीं?

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

   के उपयोग

   
   "हैलो वर्ल्ड" कार्यक्रम कुछ इस तरह दिखता है:
   
   

    import net.sf.brunneng.jom.IMergingContext; import net.sf.brunneng.jom.MergingContext; public class Main { public static class A1 { private String field1; public String getField1() { return field1; } public void setField1(String field1) { this.field1 = field1; } } public static class A2 { private String field1; public A2(String field1) { this.field1 = field1; } public String getField1() { return field1; } } public static void main(String[] args) { IMergingContext context = new MergingContext(); A2 a2 = new A2("Hello world!"); A1 a1 = context.map(a2, A1.class); System.out.println(a1.getField1()); } } 

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

    @Override public <T> T map(Object source, Class<T> destinationClass) { Snapshot sourceSnapshot = createSnapshot(source); Snapshot destSnapshot = null; if (sourceSnapshot.getRoot().getType().equals(DataNodeType.BEAN)) { Object identifier = ((BeanDataNode)sourceSnapshot.getRoot()).getIdentifier(); if (identifier != null) { destSnapshot = createSnapshot(destinationClass, identifier); } } if (destSnapshot == null) { destSnapshot = createSnapshot(destinationClass); } Diff diff = destSnapshot.findDiffFrom(sourceSnapshot); diff.apply(); return (T)destSnapshot.getRoot().getObject(); } 

   
   
   यदि स्रोत स्नैपशॉट एक बिन है, और यदि इसके पास एक पहचानकर्ता है, तो IBeanFinder का उपयोग करके गंतव्य क्लास के लिए लक्ष्य बीन खोजने का प्रयास करें [यहाँ createSnapshot(destinationClass, identifier); ]। हमने ऐसे लोगों को पंजीकृत नहीं किया, और पहचानकर्ता ने ऐसा नहीं किया, इसलिए हम आगे बढ़ते हैं। अन्यथा, सेम को उपयुक्त IObjectCreator [यहाँ createSnapshot(destinationClass) ] का उपयोग करके बनाया गया है। हमने ऐसे लोगों को पंजीकृत नहीं किया, हालांकि, मानक वितरण में डिफ़ॉल्ट निर्माता द्वारा वस्तुओं का निर्माता है - इसका उपयोग किया जाता है। अगला, स्रोत के स्नैपशॉट से अंतर को लक्ष्य स्नैपशॉट से लिया गया है और लक्ष्य पर लागू किया गया है। वह सब है।
   
   वैसे, इस साधारण मामले के लिए, अंतर, इस तरह दिखेगा:
   

    MODIFY { dest object : Main$A1@28a38b58 src object : Main$A2@76f8d6a6 ADD { dest property : String field1 = null src property : String field1 = "Hello world!" } } 

   
   
   

   कुंजी एनोटेशन

   
   वे पैकेज net.sf.brunneng.jom.annotations ।
   
   • @Mapping - एसोसिएशन के दूसरे छोर पर मैपिंग फ़ील्ड के लिए पथ सेट करता है (उदाहरण के लिए, “employee.person.firstName” । @Mapping “employee.person.firstName” )। लक्ष्य या स्रोत वस्तु की कक्षा में संकेत दिया जा सकता है।
   • @Skip - क्षेत्र स्नैपशॉट में नहीं आता है, इसकी तुलना नहीं की जाती है और यह मैप नहीं करता है।
   • @Identifier - उस क्षेत्र को चिह्नित करता है जिसे बीन की पहचानकर्ता माना जाता है। इस प्रकार, संग्रह की तुलना करते समय, हम जानेंगे कि किस वस्तु की तुलना किस वस्तु से की जानी चाहिए। अर्थात्, मेल खाने वाले पहचानकर्ताओं के साथ वस्तुओं की तुलना की जाएगी। इसके अलावा, अगर आवेदन करने की प्रक्रिया में एक बिन बनाने की आवश्यकता है, और एक ही समय में एक पहचानकर्ता को जाना जाता है, तो पहले पंजीकृत IBeanFinder का उपयोग करके इस बिन को खोजने का प्रयास होगा। इसलिए, IBeanFInder का कार्यान्वयन डेटाबेस में उदाहरण के लिए IBeanFInder खोज कर सकता है।
   • @MapFromMany - @MapFromMany रूप में ही लक्ष्य वस्तु के वर्ग पर इंगित किया गया है और आपको स्रोत ऑब्जेक्ट पर गुण की एक सरणी निर्दिष्ट करने की अनुमति देता है जिसे लक्ष्य ऑब्जेक्ट में फ़ील्ड पर मैप किया जाएगा।
   • @Converter - आपको वर्ग PropertyConverter पर @Converter PropertyConverter सेट करने की अनुमति देता PropertyConverter । - वह संपत्तियों के बीच रूपांतरण करेगा। प्रॉपर्टी कन्वर्टर की आवश्यकता तब होती है जब कई फ़ील्ड्स को एक में मैप कर रहा हो, क्योंकि उसे बस स्रोत से सभी मूल्यों को एक साथ इकट्ठा करना होगा और उनसे एक मूल्य बनाना होगा।
   • @OnPropertyChange, @OnBeanMappingStarted, @OnBeanMappingFinished - आप उन तरीकों को चिह्नित करने की अनुमति देते हैं जो इस बीन में होने वाले मैपिंग जीवन चक्र में संबंधित घटनाओं को सुनते हैं।
   • और अन्य।
   
   
   

   रूपांतरण टाइप करें

   
   IMergingContext में आप कस्टम प्रकार के कन्वर्टर्स को एक प्रकार से दूसरे ( TypeConverter इंटरफ़ेस) में पंजीकृत कर सकते हैं। कन्वर्टर्स के मानक सेट में रूपांतरण शामिल हैं:
   
   • आवरण और इसके विपरीत में आदिम प्रकार
   • दिनांक रूपांतरण
   • एक पंक्ति में वस्तुओं
   • एन्स टू एनुम्स, और स्ट्रिंग्स टू एनम्स बाय एनम एंयम
   
   
   

   वस्तुओं की श्रेणियाँ

   
   मैपर सभी वस्तुओं को श्रेणियों में विभाजित करता है जैसे:
   
   1. मान ऑब्जेक्ट: आदिम प्रकार, java.lang में ऑब्जेक्ट, दिनांक, मान ऑब्जेक्ट की सरणियाँ। मान रखने वाली कक्षाओं की सूची का विस्तार IMergingConext माध्यम से किया जा सकता है।
   2. संग्रह सरणियाँ हैं, सभी java.util.Collection से विरासत में मिली हैं।
   3. नक्शे सभी java.util.Map से विरासत में मिले हैं।
   4. बीन्स सभी बाकी हैं।
   
   
   

   उत्पादकता

   
   ईमानदारी से, जब मैं पुस्तकालय लिख रहा था, मैंने प्रदर्शन के बारे में ज्यादा नहीं सोचा। हां, और शुरू में उच्च प्रदर्शन का कोई लक्ष्य नहीं था। हालाँकि, मैंने प्रति परीक्षण ऑब्जेक्ट के लिए मैपिंग समय N बार मापने का निर्णय लिया। परीक्षण का स्रोत कोड । ऑब्जेक्ट काफी जटिल है, जिसमें मूल्य क्षेत्र, बच्चे के डिब्बे, संग्रह और नक्शे हैं। तुलना के लिए, डोजर ने इस समय नवीनतम संस्करण 5.4.0 लिया। उन्हें उम्मीद थी कि डॉसर कोई भी मौका नहीं छोड़ेगा। लेकिन यह बिल्कुल विपरीत निकला! डोजर ने 32 सेकंड में 5000 टेस्ट ऑब्जेक्ट और 8 सेकंड में जावा-ऑब्जेक्ट-मर्जर 50,000 ऑब्जेक्ट को मैप किया। अंतर कुछ जंगली है - 40 बार ...
   
   

   आवेदन

   
   मेरे मुख्य कार्य (ओसगी, वसंत, हाइबरनेट, सैकड़ों मैपिंग कक्षाएं) के बाद से वर्तमान परियोजना पर जावा-वस्तु-विलय का परीक्षण किया गया है। इसे बदलने के लिए, डॉजर को पूरी तरह से 1 दिन से भी कम समय लगा। रास्ते में कुछ स्पष्ट स्कूल थे, लेकिन ठीक करने के बाद, सभी मुख्य परिदृश्यों ने ठीक काम किया।
   
   

   आलसी स्नैपशॉट

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

   निष्कर्ष

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