जावा ओआरएम आप क्या पसंद करते हैं, और क्यों? [बन्द है]

Question

यह एक बहुत खुला सवाल है। मैं एक नई परियोजना शुरू करूंगा और डेटाबेस एक्सेस के साथ एकीकृत करने के लिए विभिन्न ओआरएम देख रहा हूं।

क्या आपका कोई पसंदीदा है? क्या कोई ऐसा है जिसके बारे में आप स्पष्ट रहने की सलाह देंगे?

Comments

इन महत्वपूर्ण संबंधित प्रश्नों को देखें: stackoverflow.com/questions/494816/use-an-orm-or-plain-sql/… stackoverflow.com/questions/716532/…

— ripper234

माइक्रो-ऑर्म्स पर नज़र डालें - प्लेटफ़ॉर्म की DB एक्सेस टेक्नोलॉजी के आसपास पतले रैपर - जैसे Java github.com/aaberg/sql2o के लिए sql2o या .NET github.com/ServiceStack/ServiceStack.OrmLite के

— tomaszkubacki

5 से अधिक वर्षों के लिए ORM का उपयोग करने के बाद मेरी व्यक्तिगत पसंद ORM पर स्प्रिंग JDBC है, और दूसरा सबसे अच्छा iBatis (MyBatis) है, मैं सीखने की अवस्था, कम नियंत्रण और प्रदर्शन के मुद्दों के कारण हाइबरनेट को नापसंद करता हूं।

यहाँ हल्की jdbc रैपरों की सूची भी बंद है जो पूर्ण-विकसित ऑर्म्स के विकल्प के रूप में इस्तेमाल की जा सकती है: stackoverflow.com/questions/7137929/…

— वडज़िम

Answer 1

मैंने ORM का उपयोग करना बंद कर दिया है।

इसका कारण अवधारणा में कोई बड़ा दोष नहीं है। हाइबरनेट अच्छी तरह से काम करता है। इसके बजाय, मैंने पाया है कि प्रश्नों में कम ओवरहेड है और मैं बहुत सारे जटिल तर्क को बड़े SQL प्रश्नों में फिट कर सकता हूं, और डेटाबेस में अपनी बहुत सी प्रसंस्करण को स्थानांतरित कर सकता हूं।

तो सिर्फ JDBC पैकेज का उपयोग करने पर विचार करें।

Comments

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

— इलको

अरे, क्या यह बड़ी वास्तविक जीवन परियोजनाओं के लिए सच है?

— संतियागोबसुल्तो

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

— मार्कोलोप्स

क्वेरी / लेनदेन की जटिलता के आधार पर दोनों का उपयोग क्यों नहीं करते? ऐसा नहीं है कि वे परस्पर अनन्य हैं।

— उभयलिंगी

@WillSheppard हाँ करेंगे। मैं Django ORM का काफी उपयोग करता हूं और यह बहुत अच्छा काम करता है। मुझे लगता है कि अंतर अजगर (और पर्ल) की गतिशील प्रकृति में हो सकता है। जावा में ORM का उपयोग करना एक दर्द है। लेकिन गतिशील भाषाओं में यह वास्तव में अभिव्यंजक हो सकता है। पायथन में डीएसएल जैसे ओआरएम संचालन को एम्बेड करने के लिए कुछ बेहतरीन परियोजनाएं हैं और महान हैं।

— 1926 में santiagobasulto

Answer 2

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

Comments

मैं इस बात से सहमत हूं। दृढ़ता कोड लिखकर कुल विकास समय का कितना उपभोग किया जाएगा? मुझे लगता है कि 10-15% से कम है

— adrian.tarau

निर्भर करता है। यकीन है, अगर आप सिर्फ एक विशेष प्रकार के डेटाबेस का उपयोग कर रहे हैं, तो ओआरएम का उपयोग नहीं करना आसान है। हालांकि, जब आपको अन्य प्रकार के डेटाबेस का समर्थन करने की आवश्यकता होती है, तो यह जल्दी से कम प्रबंधनीय हो सकता है।

— जेसन बेकर

"प्राप्त की गई समय की बचत को आसानी से उड़ा दिया जाता है जब आपको ओआरएम के उपयोग से उत्पन्न असामान्यताओं को डीबग करना पड़ता है" यह सच नहीं है जब कौशल विकल्प लेते समय कौशल वक्र एक सभ्य कारक है।

— एल्सडेक

आपका तर्क किसी भी पुस्तकालय के उपयोग के खिलाफ पेश किया जा सकता है। ओआरएम का सबसे बड़ा लाभ काम की इकाइयों, ऑब्जेक्ट मैपिंग, परिवर्तन ट्रैकिंग, आलसी लोडिंग, माइग्रेशन और रिश्ते जैसी चीजें हैं। यह user.profile.givenName लिखने में सक्षम होने के लिए एक अद्भुत बात है और इस बारे में परवाह नहीं है कि इसके लिए डेटा को संग्रहीत करने के लिए किस संरचना का उपयोग किया गया था।

— एलेक्स

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

— सिमोन

Answer 3

कई ओआरएम महान हैं, आपको यह जानना होगा कि आप जेडीबीसी के शीर्ष पर अमूर्तता क्यों जोड़ना चाहते हैं। मैं आपको http://www.jooq.org सलाह दे सकता हूं (अस्वीकरण: मैं jOOQ का निर्माता हूं, इसलिए यह उत्तर पक्षपाती है)। jOOQ निम्नलिखित प्रतिमान को गले लगाता है:

• एसक्यूएल एक अच्छी चीज है। SQL में बहुत सी चीजों को बहुत अच्छी तरह से व्यक्त किया जा सकता है। SQL के पूर्ण अमूर्तन की कोई आवश्यकता नहीं है।
• संबंधपरक डेटा मॉडल एक अच्छी बात है। यह पिछले 40 वर्षों के लिए सबसे अच्छा डेटा मॉडल साबित हुआ है। XML डेटाबेस या वास्तव में ऑब्जेक्ट ओरिएंटेड डेटा मॉडल की कोई आवश्यकता नहीं है। इसके बजाय, आपकी कंपनी Oracle, MySQL, MSSQL, DB2 या किसी अन्य RDBMS के कई उदाहरण चलाती है।
• SQL में एक संरचना और वाक्यविन्यास है। इसे JDBC में "निम्न-स्तरीय" स्ट्रिंग संघनन का उपयोग करके व्यक्त नहीं किया जाना चाहिए - या HQL में "उच्च-स्तरीय" स्ट्रिंग संघनन - जो दोनों वाक्यविन्यास त्रुटियों को पकड़ने के लिए प्रवण हैं।
• प्रमुख प्रश्नों से निपटने के दौरान परिवर्तनीय बाध्यकारी बहुत जटिल हो जाता है। यह कुछ ऐसा है जिसे अमूर्त किया जाना चाहिए।
• डेटाबेस डेटा में जावा कोड में हेरफेर करते समय POJO महान होते हैं।
• POJO मैन्युअल लिखने और बनाए रखने के लिए एक दर्द है। कोड जनरेशन जाने का रास्ता है। आपके पास डेटाटाइप-सुरक्षा सहित संकलन-सुरक्षित प्रश्न होंगे।
• डेटाबेस पहले आता है। जबकि आपके डेटाबेस के शीर्ष पर स्थित अनुप्रयोग समय के साथ बदल सकता है, डेटाबेस स्वयं संभवतः अधिक समय तक चलने वाला है।
• हां, आपके पास अपने विरासत डेटाबेस में संग्रहीत कार्यविधियाँ और उपयोगकर्ता परिभाषित प्रकार (UDT) हैं। आपके डेटाबेस-उपकरण को उसका समर्थन करना चाहिए।

कई अन्य अच्छे ओआरएम हैं। विशेष रूप से हाइबरनेट या आईबैटिस में एक महान समुदाय है। लेकिन अगर आप एक सहज, सरल की तलाश में हैं, तो मैं कहूंगा कि jOOQ को आज़माएं। आपको बहुत पसंद आएगा! :-)

इस उदाहरण की जाँच करें SQL:

  // Select authors with books that are sold out
  SELECT * 
    FROM T_AUTHOR a
   WHERE EXISTS (SELECT 1
                   FROM T_BOOK
                  WHERE T_BOOK.STATUS = 'SOLD OUT'
                    AND T_BOOK.AUTHOR_ID = a.ID);

और इसे jOOQ में कैसे व्यक्त किया जा सकता है:

  // Alias the author table
  TAuthor a = T_AUTHOR.as("a");

  // Use the aliased table in the select statement
  create.selectFrom(a)
        .whereExists(create.selectOne()
                           .from(T_BOOK)
                           .where(T_BOOK.STATUS.equal(TBookStatus.SOLD_OUT)
                           .and(T_BOOK.AUTHOR_ID.equal(a.ID))))));

Comments

ORM उपकरण उतने ही महान हैं जितना कि आप उन्हें ठीक से उपयोग करने का प्रबंधन करते हैं। ऐसी परियोजनाएं हैं जहां ORM उपकरण एक आकर्षण की तरह काम करते हैं, जबकि दूसरों में, वे बिल्कुल भी फिट नहीं होते हैं। अंत में, यह उनकी परियोजना आवश्यकताओं के लिए सही उपकरण चुनने के लिए विकास टीम की जिम्मेदारी है। ORM उपकरण जटिल हैं। दुर्भाग्य से, सभी डेवलपर्स का केवल एक हिस्सा यह समझने में समय बिताएगा कि वे कैसे काम करते हैं। बाकी उपकरण को दोष देंगे और कहेंगे कि यह खराब है। सवाल यह है: क्या सबसे उत्तोलित उत्तर सबसे अच्छी सलाह प्रदान करता है? > तो बस JDBC पैकेज का उपयोग करने पर विचार करें। क्या हम वास्तव में सादे JDBC का उपयोग करना चाहते हैं?

— व्लाद मिहालसी 13

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

— 21

Answer 4

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

इसे .NET (NHibernate) में भी पोर्ट किया गया है, ताकि आप इसे वहां भी इस्तेमाल कर सकें।

Comments

मैं हिब भी वोट है, लेकिन एक महत्वपूर्ण इसके अलावा के साथ: हम जेपीए एपीआई का उपयोग करना चाहिए केवल जेपीए कार्यान्वयन हिब द्वारा प्रदान की वास्तव में भले ही।

— व्लादिमीर Dyuzhev

Answer 5

हाइबरनेट करें, क्योंकि यह:

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

ORM का उपयोग करने के लिए (और क्यों) पर कुछ बिंदु:

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

Comments

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

— अमीर पाशेजादेह

Answer 6

मैं MyBatis का उपयोग करने की सलाह दूंगा । यह JDBC के ऊपर एक पतली परत है, मेज पर वस्तुओं को मैप करना बहुत आसान है और अभी भी सादे एसक्यूएल का उपयोग करते हैं, सब कुछ आपके नियंत्रण में है।

Comments

कॉम्प्लेक्स रीड्स के लिए इबैटिस, और बनाने के लिए हाइबरनेट, अपडेट डिलीट और सिंपल रीड्स परफेक्ट चॉइस है।

— दरपेट

Answer 7

जब मैं एक मध्यम आकार के JavaSE एप्लिकेशन को लिख रहा था तो मुझे Avaje Ebean के साथ वास्तव में अच्छा अनुभव था।

यह संस्थाओं को परिभाषित करने के लिए मानक JPA एनोटेशन का उपयोग करता है, लेकिन एक बहुत ही सरल API (कोई EntityManager या उस संलग्न / अलग संस्थाओं में से कोई भी बकवास) को उजागर नहीं करता है। यह आवश्यक होने पर आपको आसानी से SQL क्वेरी या ईवेंट सादे JDBC कॉल का उपयोग करने देता है।

इसमें प्रश्नों के लिए एक बहुत अच्छा तरल पदार्थ और प्रकार-सुरक्षित एपीआई भी है। आप इस तरह की बातें लिख सकते हैं:

List<Person> boys = Ebean.find(Person.class)
                                  .where()
                                       .eq("gender", "M")
                                       .le("age", 18)
                                  .orderBy("firstName")
                                  .findList();

Comments

मुझे थोड़ा अजीब होना चाहिए ... पर्सन से चुनें जहां लिंग = 'एम' और उम्र <18 फर्स्ट नेम द्वारा ऑर्डर किया गया है बस मुझे इतना अच्छा लगता है :-)

— इलको

यह जावा में मैंने देखा है बेहतर orms में से एक है। यह एक सिंगलटन का उपयोग करने का निर्णय है जो ताज़ा है और यह दूसरों पर एक बड़े पैमाने पर व्यावहारिक लाभ देता है।

— opsb

मुझे लगता है कि आप धाराप्रवाह तरल पदार्थ नहीं मतलब है ।

— मोंटेटिडियर

@ मुझे लगता है कि तकनीकी रूप से यह एक एकल है, एक एकल नहीं है।

— मोनाटिडियर

Avaje Ebean ORM के साथ कैसे शुरुआत करें? किसी भी वीडियो ट्यूटोरियल ??

— अविनाश

Answer 8

सरल , क्योंकि यह सीधा-आगे है और कोई जादू नहीं है। यह जावा कोड में सभी मेटा डेटा संरचनाओं को परिभाषित करता है और बहुत लचीला है।

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

लेकिन हाइबरनेट के विपरीत, SimpleORM एक बहुत ही सरल वस्तु संरचना और वास्तुकला का उपयोग करता है, जो जटिल पार्सिंग, बाइट कोड प्रोसेसिंग आदि की आवश्यकता से बचा जाता है। सिंपल छोटा और पारदर्शी होता है, आकार में सिर्फ 79K और 52K के दो जार में पैक किया जाता है, जिसमें केवल एक छोटा और वैकल्पिक होता है। निर्भरता (Slf4j)। (हाइबरनेट 2400K प्लस से अधिक 2000K निर्भर जार के बारे में है।) इससे सिंपल को समझना आसान हो जाता है और इसलिए तकनीकी जोखिम बहुत बढ़ जाता है।

Comments

इसका उपयोग नहीं किया गया, लेकिन ActiveObjects ने खुद को अपनी वेबसाइट पर हाइबरनेट-लाइट के रूप में वर्णित किया है, इसलिए संभवतः कुछ समानता है।

— अब्दुल्ला जिबली

Answer 9

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

ओह और एक्लिप्स लिंक को जेपीए 2.0 के लिए संदर्भ कार्यान्वयन के लिए चुना गया है

Answer 10

जब मैं फ्री-फ़ॉर्म SQL प्रश्नों के लिए जावा प्रतिस्थापन के बारे में चिंताओं को साझा करता हूं, तो मुझे वास्तव में लगता है कि ORM की आलोचना करने वाले लोग आमतौर पर खराब एप्लिकेशन डिज़ाइन के कारण ऐसा कर रहे हैं।

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

Comments

यदि आप किसी निरंतर स्टोर के शीर्ष पर एप्लिकेशन बना रहे हैं, जैसे हम में से कई, चाहे वह RDBMS हो या कोई NoSQL स्वाद हो, तो उस स्टोर के पास इसे एक्सेस करने का एक कुशल तरीका होगा। इससे बहुत अधिक अमूर्त करने की कोशिश सिर्फ अतिरंजना है। 'सच्चे OOD' के बारे में अत्यधिक उत्साही होने के कारण उन अंतरिक्ष यात्री आर्किटेक्चर को जावा के लिए बदनाम किया जाता है।

— इलको