आप एक नए जावा दृढ़ता उपकरण के बारे में क्या सोचेंगे, यह वास्तव में ORM नहीं है? [बन्द है]

Question

जावा में दृढ़ता

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

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

jOOQ

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

• SQL पर आधारित एक डोमेन विशिष्ट भाषा
• स्रोत कोड पीढ़ी जावा के लिए अंतर्निहित डेटाबेस स्कीमा मैपिंग
• कई RDBMS के लिए समर्थन

कुछ सुविधाओं को जोड़ना जो कुछ आधुनिक दृढ़ता के उपकरण हैं (मुझे गलत होने पर सही करें):

• जटिल एसक्यूएल के लिए समर्थन - यूनियनों, नेस्टेड चयन, स्व-जॉइन, अलियासिंग, केस क्लॉज, अंकगणितीय अभिव्यक्ति
• गैर-मानक एसक्यूएल - संग्रहीत प्रक्रियाओं, यूडीटी, ईएनयूएमएस, देशी कार्यों, विश्लेषणात्मक कार्यों के लिए समर्थन

: कृपया अधिक जानकारी के लिए प्रलेखन पेज पर विचार http://www.jooq.org/learn.php । आप देखेंगे कि Linq में C # के लिए बहुत ही समान दृष्टिकोण लागू किया गया है, हालांकि Linq SQL के लिए विशेष रूप से डिज़ाइन नहीं किया गया है।

प्रश्न

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

महत्वपूर्ण लेकिन रचनात्मक जवाब की सराहना की

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

Comments

क्या यह लेनदेन को संभालता है?

— आर्मंड

@ एलिसन: नहीं, यह सिर्फ SQL के बारे में है। लेन-देन हैंडलिंग एक बहुत ही जटिल व्यवसाय है जो मुझे लगता है कि कई अन्य उपकरण / रूपरेखा (EJB2 / 3 सहित) jOOQ से बेहतर तरीके से संभालेंगे

— लुकास ईडर

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

यह भी ध्यान दें कि THIS को संपादित करने से उत्तर अधिक या कम अप्रासंगिक होंगे और इसलिए भविष्य के पाठकों के लिए अनुपयोगी होंगे। इसके बजाय एक नया और बेहतर सवाल पूछें।

हाय थोरबॉर्न। आप उदाहरण पृष्ठ पर दिखाए गए के अलावा एक उपयोग-केस का मतलब है? या आप स्वयं प्रश्न में कुछ उदाहरण देखना चाहेंगे? संपादन के बारे में: आप सामान्य रूप से सही हैं। इस मामले में, हालाँकि, मुझे लगा कि मुझे अब तक मिले दो उत्तर कुछ हद तक एक जैसे लगे ...

— लुकास एडर

Answer 1

मुझे लगता है कि आप सही रास्ते पर हैं और आपके समाधान के साथ जारी रहना चाहिए। पिछली आलोचना में से कुछ अत्यधिक कठोर है, लेकिन कुछ मान्य बिंदु बनाए गए हैं।

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

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

दुर्भाग्य से, मेरा आवेदन क्रंचिंग किस्म का अधिक है (हालांकि कुछ CRUD भी है), इसलिए मैंने अपना रोल करने का फैसला किया। मैं शुरू से जानता था कि यह वहाँ से बाहर अन्य समाधानों की तुलना में सब बराबर होगा, लेकिन यह काफी अच्छा होगा और मुझे उस प्रदर्शन की आवश्यकता होगी जो मुझे चाहिए। अब यहाँ वास्तव में महान हिस्सा है: यह आपके समाधान की तरह दिखता है!

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

आपका समाधान समस्या को बेहतर ढंग से परिष्कृत करता है, लेकिन यह केवल इसका एक हिस्सा हल करता है। मुझे लगता है कि एक स्तरित दृष्टिकोण हमें वह सब कुछ दे सकता है जो हम चाहते हैं। जो आप / IMO के साथ आए हैं, वह नींव की परत है। जैसा कि आपने सुझाव दिया है, मुझे लगता है कि यह परत डेटाबेस स्कीमा के आधार पर स्वचालित रूप से उत्पन्न होती है। यह एक बहुत ही सरल संबंधपरक ऑब्जेक्ट मॉडल होना चाहिए जो सीधे डेटाबेस पर मैप करता है और अधिक नहीं। आप सही कह रहे हैं कि डेटा कोड की तुलना में अधिक समय तक बना रहता है, इसलिए इस स्तर पर डेटा को कोड ड्राइव करना चाहिए, न कि इसके विपरीत। यह CRUD के साथ-साथ प्रदर्शनकारी थोक क्वेरी का समर्थन करेगा। मैं शायद इस लेयर पर किसी तरह का L1 कैश लागू करूंगा।

हालाँकि, अन्य ORM समाधानों में जो चीज उत्कृष्ट है वह आपकी वस्तुओं को इस तरीके से परिभाषित करने की क्षमता है जो अंतर्निहित डेटाबेस की वास्तविक संरचना पर इतना निर्भर नहीं करती है। इस कार्यक्षमता के लिए, मैं एक और परत बनाऊंगा। आवश्यकता से यह परत अधिक सारगर्भित हो जाती है, उम्मीद है कि सरलता (खोई हुई कार्यक्षमता की कीमत पर), और पिछली परत पर बनती है। यह एक L2 कैश का उपयोग कर सकता है।

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

मुझे लगता है कि आपके पास अंतरिक्ष की समझ है और पहिया को फिर से मजबूत नहीं किया जा रहा है, बल्कि थोड़ा अलग जगह मारा है। और सच कहूँ तो, यह एक पहिया है जो वैसे भी सुधार का उपयोग कर सकता है। आप अतीत के पॉवरहाउस के खिलाफ एक कठिन लड़ाई का सामना करते हैं, लेकिन अगर आपका समाधान अच्छा है, और मुझे लगता है कि यह इस तरह से बढ़ रहा है, तो यह अपने गुणों के दम पर लोकप्रियता हासिल करेगा।

Comments

हाय डेल, आपके प्रोत्साहन के लिए धन्यवाद! मैं परतों और jOOQ के बारे में आपके वाक्यांशों को पसंद करता हूं जो jOOQ के शीर्ष पर आगे की अमूर्तता के साथ सबसे निचली परत पर होता है। यह एक ऐसी चीज है जिससे मैं निपटना चाहता हूं जब मेरे पास jOOQ के साथ पर्याप्त गति हो। जेपीए और / या हाइबरनेट के साथ इंटरफेसिंग स्पष्ट रूप से रोडमैप पर होगा। जैसा कि आप इसे कहते हैं, ये उपकरण अमूर्तता के माध्यम से सरलता में उत्कृष्टता प्राप्त करते हैं और कई विशेषताएं हैं जो मुझे अपनी परत में नहीं चाहिए: लेनदेन, सत्र, L2 कैश, आदि। PS: क्या सार्वजनिक डोमेन में आपका खुद का समाधान है? मुझे बहुत दिलचस्पी होगी!

— लुकास एडर

Answer 2

"वहाँ बहुत सारे जादू की गोलियां हैं, और भोले डेवलपर्स की कोई कमी नहीं है।"

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

Comments

आपकी प्रतिक्रिया के लिए धन्यवाद! क्या आपने मेरे पुस्तकालय को और अधिक गहराई से देखा है? मैं ठीक से "ओ को त्यागने" का प्रयास करता हूं कि आपका लेख इसे कैसे कहता है। jOOQ चाहता है कि डेवलपर्स SQL ​​लिखें, न कि OR-Mapped कोड। मैं कोशिश करता हूं कि Java कंपाइलर को फिर से लिखने में सक्षम हुए बिना Linq के लिए क्या करना है। Linq के लिए Microsoft को बधाई! और मैं यह कहने की हिम्मत करता हूं कि मैं अनुभवहीन नहीं हूं, क्योंकि मैंने ईजेबी 2.0 (काफी समय पहले) और न ही हाइबरनेट के साथ संतुष्ट नहीं होने के बाद jOOQ बनाया। उन कारणों के लिए जो आप अपने लेख में बताते हैं। मैंने कोशिश की कि क्या किया गया है और यह मेरी आवश्यकताओं के अनुरूप नहीं है।

— लुकास एडर

jOOQ चाहता है कि डेवलपर्स आपके मानदंड जैसे API का उपयोग करें। वह एसक्यूएल नहीं है। यह एसक्यूएल बनाने का एक तरीका है कि वास्तव में एसक्यूएल की तुलना में बदसूरत और अधिक जटिल है, यदि कोई है, तो वास्तविक लाभ। "q.addCompareCondition (TAuthor.YEAR_OF_BIRTH, 1920, Comparator.GREATER);" मैं वास्तव में किसी भी अन्य वर्ग-प्रति-तालिका जनरेशन टूल से अलग कुछ भी नहीं देखता हूं। जिसका अर्थ है, जैसा कि मैंने कहा, लगभग एक निश्चित संभावना है कि एक बेहतर पहले से मौजूद है। टेम्प्लेट-जनित स्ट्रिंग फ़ील्ड भी नहीं आती हैं जो लैम्ब्डा एक्सप्रेशन को सक्षम बनाती हैं।

— क्वेंटिन-स्टारिन

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

— लुकास एडर

Answer 3

एक ऐसा परिदृश्य जो इस तरह के एपीआई को अच्छी तरह से अनुकूल बना देगा, वह है जब आपको एक डेटाबेस-एग्नॉस्टिक एसक्यूएल बिल्डर की आवश्यकता होती है जो अधिकांश ओआरएम आपको अनुमति नहीं देता है। एक बड़ी स्थिति जहां मुझे इसकी आवश्यकता है, रिपोर्ट बनाने में है। मुझे एक ऑब्जेक्ट ओरिएंटेड तरीके से SQL बनाने और परीक्षण के लिए विभिन्न डेटाबेस पर इस sql को चलाने की आवश्यकता है। हाइबरनेट और अन्य ओआरएम विन्यास पर बहुत निर्भर हैं, इस प्रकार मेरे एसक्यूएल निर्माण को सीमित कर रहा है जैसे कि मैं टेबल को गठबंधन नहीं कर सकता जहां एसोसिएशन एक्सएमएल में मौजूद नहीं है। चूंकि रिपोर्ट मॉड्यूल मैं विकसित कर रहा हूं, इसलिए कोई भी संघ संभव है, मैंने कुछ अलग देखा है। फिर मैं JOOQ में आया। यह सिर्फ मेरी समस्या को हल करता है। मुझे सिर्फ एक रीड ओनली एक्सेस की जरूरत है, हाइबरनेट जैसे दर्दनाक डिबगिंग मुद्दों का सामना कभी न करें।

मैं वास्तव में आम POJO तरीके के बजाय मॉडलिंग डेटा का एक अलग तरीका विकसित करने और JOOQ का उपयोग करने के लिए एक नींव के रूप में उपयोग करने की योजना बना रहा हूं जो SQL बनाने के लिए एक परत है। इसलिए JOOQ के शीर्ष पर, मैं HashMaps का उपयोग करके मॉडलिंग डेटा / संस्थाओं का अधिक लचीला तरीका बनाने की योजना बना रहा हूं। मेरा डिज़ाइन एक प्रविष्टि बिंदु में सामने के छोर और बैकएंड डिज़ाइन को आसान बनाने के लिए संभव बनाता है, हालांकि मैं रूपरेखा को पूरा करने के लिए विभिन्न परतों का उपयोग करूंगा, जैसे कि ऊपर की टिप्पणियों ने कहा है। JOOQ वास्तव में मेरे स्वयं के प्रोजेक्ट की तरह एक बहुत अच्छा हिस्सा निभाएगा, यह नींव या स्तंभों में से एक के रूप में कार्य करता है।

इसलिए अच्छे काम का लुत्फ़ उठाते रहो!

Answer 4

अगर मैं आपके टूल को सही तरीके से समझता हूं, तो यह ऑब्जेक्ट्स को मैप करने के बजाय सीधे एक वैचारिक एसक्यूएल फ्रेमवर्क पर मैप करता है। एसक्यूएल फंक्शनलिटी (ओआरएम) पर कुछ मैपिंग को लागू करने वाले ऑब्जेक्ट्स की तरह, लगभग geeky कंट्रोल के लिए ORM-- एब्स्ट्रक्शन की तरह होता है ताकि आप अपने एसक्यूएल फीचर्स का इस्तेमाल कर सकें ORM आमतौर पर आपको नहीं देगा?

निश्चित नहीं है कि आप किस समस्या को हल करने का प्रयास कर रहे हैं। चूँकि आपके उपकरण को SQL के गहन ज्ञान की आवश्यकता है, क्या लोग सिर्फ SQL का उपयोग नहीं करेंगे? क्या यह वह गोंद-कोड है जिससे आप छुटकारा पाने की कोशिश कर रहे हैं? सरल स्ट्रिंग्स के बजाय एपीआई मॉडलिंग के माध्यम से एसक्यूएल प्रश्नों का बेहतर सत्यापन?

मुझे यह स्वीकार करना होगा कि आपके JOOQ उदाहरण SQL के LISP संस्करणों की तरह दिखते हैं। ऐसा नहीं है कि एक बुरी बात है :) और मुझे कुछ उन्नत सामान दिलचस्प दिख रहे हैं, लेकिन आपके द्वारा सूचीबद्ध फायदे धीरे-धीरे गायब होते जा रहे हैं क्योंकि आप विशिष्ट एसक्यूएल के आंतरिक गर्भगृह में अधिक उन्नत (कम विन्यास, कम सार, अधिक अंतर्धान हो जाते हैं) इंजन, आदि)

एक सुझाव है कि मैं यह देखना चाहता हूं कि मुझे सबसे ORM में याद आती है एक फ्रेमवर्क है जो वस्तुओं के साथ एक गैर-संबंधपरक तरीके से निपट सकता है, जो भी बैकएंड हो सकता है उसमें ऑब्जेक्ट इंटरैक्शन का अनुवाद करना (SQL, NoSQL, Topic Maps, RDF, आदि) ।) जिसे SQL इंटरैक्शन, बोलियों और संबंधपरक सोच की बारीकियों के बजाय उपयोग किए जाने वाले मॉडल के कैशिंग की आवश्यकता होती है ।

IMHO, बिल्कुल। :)

Comments

नमस्ते वहाँ, आपकी प्रतिक्रिया के लिए धन्यवाद। तुमने सही समझा। जैसा कि qstarin ने रखा है, मैं ORM से "O" को हटाने और रिलेशनल रहने का प्रयास करता हूं। सादा एसक्यूएल क्यों नहीं? आपका मतलब है JDBC? क्या आपने कभी अपने डेटाबेस को 5 नेस्टेड चयन और कई जॉइन, जेडीबीसी के साथ विश्लेषणात्मक कार्यों के साथ क्वेर किया है? सिंटैक्स त्रुटियाँ, बाइंडिंग मिसमैच, आदि दुर्भाग्य से, jOOQ आपके लिए सही उपकरण नहीं हो सकता है, क्योंकि किसी भी मॉडल को ऑब्जेक्ट में मैप करने की कोई संभावना नहीं है । और मैं ऐसा नहीं चाहता। jOOQ चाहिए रिलेशनल हो। उन डेवलपर्स के लिए जो सोचने के तरीके को पसंद करते हैं। दूसरे के लिए मैं JPA की सलाह देता हूं .. या Linq यदि आप .NET कर रहे हैं

— लुकास एडर