क्या ORM का उपयोग न करने के अच्छे कारण हैं? [बन्द है]

Question

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

हालाँकि, मैं NHibernate या इसी तरह की परियोजना का उपयोग नहीं करने के दो मुख्य कारणों को पूरी तरह से नहीं समझता:

1. कोई बस SQL ​​प्रश्नों के साथ अपने डेटा एक्सेस ऑब्जेक्ट का निर्माण कर सकता है और उन प्रश्नों को Microsoft SQL सर्वर प्रबंधन स्टूडियो से बाहर कर सकता है।
2. एक ORM डीबग करना कठिन हो सकता है।

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

इसके अलावा, NHibernate का उपयोग करके आप अप्रत्याशित समस्याओं में भाग सकते हैं यदि आप रूपरेखा को अच्छी तरह से नहीं जानते हैं। उदाहरण के लिए, Table.hbm.xml पर भरोसा करना, जहां आप एक स्ट्रिंग की लंबाई को स्वचालित रूप से मान्य किया जा सकता है। हालाँकि, मैं "साधारण" SqlConnection क्वेरी आधारित डेटा एक्सेस लेयर में समान बग्स की कल्पना भी कर सकता हूँ।

अंत में, क्या उन तर्कों का उल्लेख किया गया है जो वास्तव में एक गैर-तुच्छ डेटाबेस आधारित उद्यम अनुप्रयोग के लिए ओआरएम का उपयोग नहीं करने का एक अच्छा कारण है? वहाँ शायद अन्य तर्क वे / मैं याद किया हो सकता है?

(मुझे शायद यह जोड़ना चाहिए कि मुझे लगता है कि यह पहले "बड़े" .NET / C # आधारित अनुप्रयोग की तरह है जिसे टीमवर्क की आवश्यकता होगी। अच्छा अभ्यास, जिसे स्टैक ओवरफ्लो पर बहुत सामान्य के रूप में देखा जाता है, जैसे कि यूनिट परीक्षण या निरंतर एकीकरण, गैर हैं। -अभी तक यहां मौजूद है।)

Answer 1

हाल के वर्षों में ORM के साथ विकास का एक विस्फोट हुआ है और आपके अधिक अनुभवी सहकर्मी अभी भी "हर डेटाबेस कॉल एक संग्रहीत प्रक्रिया के माध्यम से होना चाहिए" मानसिकता में सोच रहे हैं।

एक ORM डिबग करने के लिए चीजों को कठिन क्यों करेगा? आपको वही परिणाम प्राप्त होगा, चाहे वह संग्रहित प्रोक्योर से हो या ओआरएम से।

मुझे लगता है कि मैं केवल एक ORM के साथ सोच सकते हैं कि वास्तविक सुरक्षा का अनुमान है कि सुरक्षा मॉडल थोड़ा कम लचीला है।

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

Comments

हार्ड डिबग करने के लिए: यदि एक अपवाद को फेंक दिया जाता है, तो आपको शायद SqlConnection के अपवादों आदि को जानने के बजाय फ्रेमवर्क को जानना होगा

— हेंगि

क्या sql अपवाद ORM अपवाद का हिस्सा नहीं होगा?

— जियोवानी गैल्बो

हां, सबसे अधिक अपवाद को लपेटें, इसलिए आप अभी भी मूल अपवाद को प्राप्त करने में सक्षम होंगे। थिनर

— मैट्लेंट

जैसा कि मैंने कहा, मैंने उस तर्क को नहीं लाया। :) बेशक, वास्तविक एसक्यूएल अपवाद स्टैक ट्रेस के नीचे कहीं होना चाहिए। जैसा कि आप मेरे प्रश्न से पढ़ सकते हैं, मैं आपके उत्तर से सहमत हूं, लेकिन मैं इसे स्वीकार करने के साथ प्रतीक्षा करूंगा। हो सकता है कि कोई और ORM के खिलाफ वास्तव में अच्छे कारणों के साथ आता है।

— हेंगी

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

— उड़ी अब्रामसन

Answer 2

संक्षिप्त उत्तर हां है, वास्तव में अच्छे कारण हैं। तथ्य की बात के रूप में ऐसे मामले हैं जहां आप सिर्फ एक ORM का उपयोग नहीं कर सकते हैं।

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

Comments

मुझे लगता है कि यह वर्तमान ओआरएम पुस्तकालयों की अधिक सीमा है जो एक मौलिक सीमा या मैपिंग की तुलना में संग्रहीत प्रक्रियाओं का समर्थन नहीं करते हैं। वहाँ orm है कि संग्रहीत proc और विचारों को संभाल सकते हैं और orm + संग्रहीत procs समाधान के लिए कहने के लिए बहुत कुछ है।

— Mendelt

एक अच्छे ORM के मामले में, आपको इसे वैसे भी SPs का उपयोग करने में सक्षम होना चाहिए (बेशक, यह बहुत सारे लाभों को कम करता है ...)

— kͣeͣmͮpͥ

एक ORM की तुलना में SPs वास्तव में अधिक सुरक्षा क्यों प्रदान नहीं करता है इसका विषय अच्छी तरह से ग्राउंडेड ग्राउंड है। यहाँ सिर्फ एक लेख है जो इसे अच्छी तरह से संबोधित करता है: ayende.com/Blog/archive/2007/11/18/…

— टिम स्कॉट

ठीक है, Sql Server 2005 में आप सिर्फ ORM परत के लिए डेटाबेस में स्कीमा नहीं बना सकते हैं? या यह पर्याप्त नहीं है? यदि एप्लिकेशन वेब एप्लिकेशन हैं, तो एक बात db से कनेक्ट हो रही है। सुरक्षा फिर आवेदन परत पर छोड़ दिया।

— न्यूनतम

बेशक आप प्रतिबंधित कर सकते हैं कि उपयोगकर्ता एक ओआरएम के साथ क्या कर सकता है। आप बस SQL ​​में उपयोगकर्ता सुरक्षा सेटिंग्स सेट करते हैं और उन्हें डालने / अपडेट / हटाने के लिए जो आप चाहते हैं, उन्हें निजीकृत करते हैं। यह संग्रहीत प्रक्रियाओं के लिए सुरक्षा privelages स्थापित करने के समान होगा

— डॉक्टर जोन्स

Answer 3

ORM का मधुर स्थान

ORM उन प्रश्नों के 95% + को स्वचालित करने के लिए उपयोगी है जहां वे लागू हैं। उनकी विशेष ताकत वह है जहां आपके पास एक मजबूत ऑब्जेक्ट मॉडल आर्किटेक्चर और एक डेटाबेस है जो उस ऑब्जेक्ट मॉडल के साथ अच्छी तरह से खेलता है। यदि आप एक नया निर्माण कर रहे हैं और आपकी टीम में मजबूत मॉडलिंग कौशल है, तो संभवतः आपको ORM के साथ अच्छे परिणाम मिलेंगे।

आप अच्छी तरह से मुट्ठी भर प्रश्नों को हाथ से कर सकते हैं। इस मामले में, इसे संभालने के लिए कुछ संग्रहीत प्रक्रियाओं को लिखने से डरो मत। यहां तक ​​कि अगर आप अपने ऐप को कई DBMS प्लेटफार्मों पर पोर्ट करने का इरादा रखते हैं, तो डेटाबेस डिपेंडेंट कोड अल्पसंख्यक में होगा। इस बात को ध्यान में रखते हुए कि आपको किसी भी प्लेटफ़ॉर्म पर अपने एप्लिकेशन का परीक्षण करना होगा, जिस पर आप इसका समर्थन करना चाहते हैं, कुछ संग्रहीत प्रक्रियाओं के लिए थोड़े से अतिरिक्त पोर्टिंग प्रयास आपके TCO पर बहुत अधिक फर्क नहीं डालेंगे। पहले सन्निकटन के लिए, 98% पोर्टेबल 100% पोर्टेबल जितना ही अच्छा है, और ORM की सीमा के आसपास काम करने के लिए जटिल या खराब प्रदर्शन करने वाले समाधानों से कहीं बेहतर है।

मैंने पूर्व दृष्टिकोण को बहुत बड़े (100 वर्ष के स्टाफ-वर्ष) J2EE प्रोजेक्ट पर अच्छी तरह से काम करते देखा है।

जहां एक ORM सबसे अच्छा फिट नहीं हो सकता है

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

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

• एक भिन्नता वह जगह है जहाँ आप एक डेटा मॉडल प्राप्त करते हैं जो जरूरी नहीं कि OR मैपिंग के अनुकूल हो। यदि (उदाहरण के लिए) आप एक इंटरफ़ेस लिख रहे हैं जो एक विदेशी इंटरफ़ेस से डेटा को पॉप्युलेट या अर्क करता है, तो आप डेटाबेस के साथ काम करना बेहतर हो सकते हैं।

• वित्तीय अनुप्रयोग या अन्य प्रकार के सिस्टम जहां क्रॉस-सिस्टम डेटा अखंडता महत्वपूर्ण है, खासकर यदि आप दो-चरण प्रतिबद्ध के साथ जटिल वितरित लेनदेन का उपयोग कर रहे हैं। ORM को समर्थन देने में सक्षम होने की तुलना में आपको अपने लेन-देन को बेहतर ढंग से व्यवस्थित करने की आवश्यकता हो सकती है।

• उच्च-प्रदर्शन अनुप्रयोग जहां आप वास्तव में अपने डेटाबेस एक्सेस को ट्यून करना चाहते हैं। इस मामले में, निचले स्तर पर काम करना बेहतर हो सकता है।

• ऐसी स्थितियाँ जहाँ आप ADO.Net जैसे असाध्य डेटा एक्सेस तंत्र का उपयोग कर रहे हैं, जो 'काफी अच्छा' है और मंच के साथ अच्छी तरह से खेलना ओआरएम लाता है की तुलना में अधिक लाभ है।

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

Comments

"या अन्य प्रकार के सिस्टम जहां डेटा अखंडता महत्वपूर्ण है" ... सामाजिक वेबसाइट एक तरफ, यदि आपके डेटा की अखंडता महत्वपूर्ण नहीं है, तो सिस्टम को बनाने में परेशान क्यों करें?

— ओबीवैनकोबी

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

— कंसर्नडऑफटुनब्रिजवेल्स

मुझे पता है कि यह एक वर्ष से अधिक हो गया है, लेकिन आपके लिए +1 इस तथ्य का उल्लेख करने के लिए है कि कभी-कभी डेटा बस इतना ही होता है, डेटा।

— luis.espinal

Answer 4

सबसे पहले - ORM का उपयोग करने से आपके कोड को परीक्षण करने में कोई आसानी नहीं होगी, और न ही यह एक सतत एकीकरण जेनरेटर में कोई लाभ प्रदान करेगा।

मेरे अनुभव में, ORM का उपयोग करते हुए विकास की गति को बढ़ाया जा सकता है, सबसे बड़े मुद्दे जिन्हें आपको संबोधित करने की आवश्यकता है:

1. अपने कोड का परीक्षण
2. अपने कोड को बनाए रखना

इनके समाधान इस प्रकार हैं:

1. अपने कोड को परीक्षण योग्य बनाएं ( ठोस सिद्धांतों का उपयोग करके )
2. अधिक से अधिक कोड के लिए स्वचालित परीक्षण लिखें
3. जितनी बार संभव हो स्वचालित परीक्षण चलाएं

आपके सवाल पर आते हैं, आप जिन दो आपत्तियों को सूचीबद्ध करते हैं, वे किसी और चीज़ की तुलना में अज्ञानता की तरह लगते हैं।

हाथ से सेलेक्ट क्वेश्चन को लिखने में सक्षम नहीं होना (जो, मुझे लगता है, यही कारण है कि कॉपी-पेस्ट की आवश्यकता है) इंगित करता है कि कुछ एसक्यूएल प्रशिक्षण की तत्काल आवश्यकता है।

ORM का उपयोग न करने के दो कारण हैं:

1. यह कंपनी की नीति द्वारा कड़ाई से मना किया गया है (जिस स्थिति में मैं कहीं और काम करूंगा)
2. यह परियोजना अत्यंत डेटा गहन है और विक्रेता विशिष्ट समाधानों (जैसे बल्कइनर) का उपयोग करने से अधिक समझ में आता है।

ORM (विशेष रूप से NHibernate) के बारे में सामान्य बगावतें हैं:

1. गति

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

2. जटिलता

   जटिलता के संबंध में, ORM का उपयोग करने का अर्थ है कम कोड, जिसका अर्थ है आमतौर पर कम जटिलता। हाथ से लिखे (या कोड जनरेट किए गए) डेटा एक्सेस का उपयोग करने वाले बहुत से लोग खुद को "निम्न-स्तर" डेटा एक्सेस लाइब्रेरी (जैसे ADO.Net के लिए सहायक तरीके लिखना) पर अपना खुद का ढांचा लिखते हैं। ये अधिक जटिलता के समान हैं, और, अभी तक बदतर, वे शायद ही कभी अच्छी तरह से प्रलेखित हैं, या अच्छी तरह से परीक्षण किए गए हैं।
   यदि आप विशेष रूप से NHibernate को देख रहे हैं, तो धाराप्रवाह NHibernate और Linq To NHibernate जैसे उपकरण भी सीखने की अवस्था को नरम करते हैं।

पूरे ORM डिबेट के बारे में मुझे जो बात मिलती है वह यह है कि वही लोग जो दावा करते हैं कि ORM का उपयोग करना बहुत कठिन / धीमा होगा / जो बहुत ही वही लोग हैं जो Linq To Sql या Typed Datasets का उपयोग करके अधिक खुश हैं। जबकि Linq To Sql सही दिशा में एक बड़ा कदम है, यह अभी भी प्रकाश वर्ष है जहां कुछ खुले स्रोत ORM हैं। हालाँकि, टाइप किए गए डेटासेट और लाइनक टू सकल दोनों के लिए रूपरेखा अभी भी बेहद जटिल है, और (तालिका = कक्षा) + (मूल सीआरयूडी) के बहुत दूर जाने के लिए उनका उपयोग करना मुश्किल है।

मेरी सलाह यह है कि यदि, दिन के अंत में, आप एक ORM प्राप्त नहीं कर सकते हैं, तो सुनिश्चित करें कि आपका डेटा एक्सेस बाकी कोड से अलग है, और आप कोडिंग की सलाह की गैंग का अनुसरण करते हैं एक इंटरफ़ेस। इसके अलावा, वायरिंग करने के लिए एक डिपेंडेंसी इंजेक्शन ढांचा प्राप्त करें।

(कैसे एक शेख़ी के लिए है?)

Answer 5

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

हाइबरनेट के मजबूत बिंदुओं में से एक यह है कि आपको केवल 3 बार चीजें कहने को मिलती हैं: हर संपत्ति का उल्लेख कक्षा में, .hbm.xml फ़ाइल और डेटाबेस में होता है। SQL क्वेरीज़ के साथ, आपकी प्रॉपर्टीज़ क्लास में हैं, डेटाबेस, सिलेक्ट स्टेटमेंट्स, इन्सर्ट स्टेटमेंट्स, अपडेट स्टेटमेंट्स, डिलीट स्टेटमेंट्स और आपके SQL क्वेरीज़ को सपोर्ट करने वाले सभी मार्शेलिंग और अनमर्सहॉलिंग कोड! इससे तेजी से गड़बड़ हो सकती है। दूसरी ओर, आप जानते हैं कि यह कैसे काम करता है। आप इसे डीबग कर सकते हैं। यह आपकी अपनी दृढ़ता की परत में सब ठीक है, किसी तीसरे पक्ष के उपकरण के आंत्र में दफन नहीं।

हाइबरनेट Spolsky's Leaky Abstracts के लॉ के लिए पोस्टर-चाइल्ड हो सकता है। पीटा पथ से थोड़ा दूर हो जाओ, और आपको उपकरण के गहन आंतरिक कामकाज को जानने की आवश्यकता है। यह बहुत कष्टप्रद हो सकता है जब आप जानते हैं कि आप मिनटों में एसक्यूएल को ठीक कर सकते थे, लेकिन इसके बजाय आप उचित एसक्यूएल पैदा करने में अपने खतरे के साधन को खत्म करने की कोशिश कर रहे हैं। डिबगिंग कभी-कभी एक बुरा सपना होता है, लेकिन उन लोगों को समझाना मुश्किल है जो वहां नहीं रहे हैं।

संपादित करें: यदि आप NHibernate के बारे में बदल नहीं जा रहे हैं और वे अपने SQL प्रश्नों पर नियंत्रण चाहते हैं, तो आप iBatis.NET में देखना चाहते हैं।

EDIT 2: यहां बड़ा लाल झंडा है, हालांकि: "अच्छी प्रथाएं, जो स्टैक ओवरफ्लो पर बहुत सामान्य दिखाई देती हैं, जैसे कि यूनिट परीक्षण या निरंतर एकीकरण, अब तक यहां मौजूद नहीं हैं।" तो, ये "अनुभवी" डेवलपर्स, उन्हें विकसित करने में क्या अनुभव है? उनकी नौकरी की सुरक्षा? ऐसा लगता है कि आप उन लोगों में शामिल हो सकते हैं जो विशेष रूप से क्षेत्र में रुचि नहीं रखते हैं, इसलिए उन्हें अपने हित को मारने न दें। आपको संतुलन होना चाहिए। लड़ाई करो।

Comments

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

— जोनाथन-स्टैफ़ोर्ड

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

8 साल बीत चुके हैं, लेकिन यह अभी भी सच है: "यह बहुत कष्टप्रद हो सकता है जब आप जानते हैं कि आप मिनटों में एसक्यूएल तय कर सकते थे, लेकिन इसके बजाय आप उचित एसक्यूएल उत्पन्न करने में अपने खतरे के उपकरण को खत्म करने की कोशिश कर घंटों बिता रहे हैं।"

— रुस्लान Stelmachenko

Answer 6

मैंने एक परियोजना पर काम किया, जहां ओआरएम का उपयोग नहीं करना बहुत सफलतापूर्वक था। यह एक परियोजना थी

1. शुरू से ही क्षैतिज रूप से मापनीय होना चाहिए था
2. जल्दी से विकसित किया जाना था
3. अपेक्षाकृत सरल डोमेन मॉडल था

जिस समय एनएचबर्नेट को एक क्षैतिज रूप से विभाजित संरचना में काम करने के लिए लिया गया था, उस समय की तुलना में यह एक सुपर सरल डेटामापर विकसित करने में लगने वाले समय से बहुत अधिक होगा जो हमारी विभाजन योजना के बारे में जानते थे ...

इसलिए, ९ ०% परियोजनाओं में जो मैंने ओआरएम पर काम किया है, एक अमूल्य मदद रही है। लेकिन कुछ बहुत ही विशिष्ट परिस्थितियां हैं जहां मैं एक ORM का उपयोग सबसे अच्छा नहीं होने के रूप में देख सकता हूं।

Comments

आपने कुछ विशिष्ट मामलों में ORM का उपयोग करने के खिलाफ कुछ अच्छे अंक दिए। हालांकि, यह परियोजना उन 90% से संबंधित है जहां ORM संभवतः विकास और रखरखाव की लागत को कम करने में मदद कर सकता है।

— हेंगी

पूरी तरह से सहमत - सीधे अपने सवाल का जवाब नहीं देने के लिए खेद है! मेरा मानना ​​है कि जिन विशिष्ट कारणों का आपने उल्लेख किया है वे काफी अमान्य हैं :)

— माइक

क्षैतिज रूप से स्केलिंग NHibernate: blechie.com/WPierce/archive/2008/06/08/… , darioquintana.com.ar/blogging/?p=25

— मौरिसियो शेफ़र

Answer 7

मुझे पहले यह बताएं कि ORM आपके विकास के जीवन को आसान बना सकते हैं अगर ठीक से एकीकृत किया जाए, लेकिन कुछ समस्याएं हैं जहां ORM वास्तव में आपको अपनी आवश्यकताओं और लक्ष्यों को प्राप्त करने से रोक सकता है।

मैंने पाया है कि जब डिजाइनिंग सिस्टम की भारी प्रदर्शन आवश्यकताएं होती हैं, जो मुझे सिस्टम को और अधिक प्रदर्शन करने के तरीके खोजने के लिए चुनौती दी जाती हैं। कई बार, मैं एक ऐसे समाधान के साथ समाप्त होता हूं जिसमें एक भारी लेखन प्रदर्शन प्रोफ़ाइल है (जिसका अर्थ है कि हम डेटा पढ़ रहे हैं और हम डेटा पढ़ रहे हैं)। इन मामलों में, मैं अपने प्रदर्शन लक्ष्यों तक पहुँचने के लिए डेटाबेस प्लेटफ़ॉर्म की पेशकशों का लाभ उठाना चाहता हूँ (यह OLTP है, OLAP नहीं)। इसलिए यदि मैं SQL सर्वर का उपयोग कर रहा हूं और मुझे पता है कि मेरे पास लिखने के लिए बहुत सारे डेटा हैं, तो मैं बल्क इंसर्ट का उपयोग क्यों नहीं करूंगा ... ठीक है, जैसा कि आप पहले से ही खोज चुके हैं, ज्यादातर ORMS (मुझे नहीं पता कि क्या यहां तक ​​कि एक भी) बल्क इंसर्ट जैसे प्लेटफ़ॉर्म विशिष्ट लाभों का लाभ उठाने की क्षमता नहीं रखता है।

आपको पता होना चाहिए कि आप ORM और गैर- ORM तकनीकों को मिश्रित कर सकते हैं। मैंने अभी पाया है कि कुछ मुट्ठी भर मामले ऐसे हैं जहाँ ORM आपकी आवश्यकताओं का समर्थन नहीं कर सकते हैं और आपको उन मामलों के लिए उनके आसपास काम करना होगा।

Answer 8

जब आपको 50000000 रिकॉर्ड अपडेट करने की आवश्यकता होती है। एक झंडा या जो कुछ भी सेट करें।

किसी संग्रहीत कार्यविधि या मूल SQL आदेशों को कॉल किए बिना ORM का उपयोग करके ऐसा करने का प्रयास करें ..

अपडेट 1: केवल कुछ फ़ील्ड्स के साथ एक रिकॉर्ड प्राप्त करने का प्रयास करें। (जब आपके पास बहुत "विस्तृत" तालिका है)। या एक स्केलर परिणाम। इस पर ओआरएम चूसते हैं।

अद्यतन 2 : ऐसा लगता है कि EF 5.0 बीटा बैच अपडेट का वादा करता है लेकिन यह बहुत ही गर्म खबर है (2012, जनवरी)

Comments

docs.jboss.org/hibernate/core/3.3/reference/en/html/…

— dotjoe

Answer 9

एक गैर-तुच्छ डेटाबेस आधारित उद्यम अनुप्रयोग के लिए, वास्तव में ORM का उपयोग नहीं करने का कोई औचित्य नहीं है।

एक तरफ सुविधाएँ:

• ओआरएम का उपयोग नहीं करने से, आप एक समस्या को हल कर रहे हैं जो पहले से ही बड़े समुदायों या कंपनियों द्वारा महत्वपूर्ण संसाधनों के साथ बार-बार हल किया गया है।
• ORM का उपयोग करके, आपके डेटा एक्सेस लेयर का मुख्य भाग उस समुदाय या कंपनी के डीबगिंग प्रयासों से लाभान्वित होता है।

तर्क में कुछ परिप्रेक्ष्य रखने के लिए, ADO.NET का उपयोग करने के लाभों पर विचार करें। सारणीबद्ध डेटा स्ट्रीम को पार्स करने के लिए कोड लिखना।

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

एक ORM का उपयोग करने के लिए संभावित अपवाद यह होगा कि यदि आवेदन विशेष व्यापार तर्क सार को लागू करने के लिए डिज़ाइन किया गया ORM फ्रेमवर्क था, और इसे कई परियोजनाओं पर पुन: उपयोग करने के लिए डिज़ाइन किया गया था। अगर ऐसा होता तो भी, आप उन अमूर्तों के साथ एक मौजूदा ORM को बढ़ाकर तेजी से अपनाते।

अपने वरिष्ठ टीम के सदस्यों के अनुभव को कंप्यूटर विज्ञान के विकास की विपरीत दिशा में न जाने दें। मैं 23 वर्षों से पेशेवर रूप से विकसित हो रहा हूं, और एक निरंतरता पुराने स्कूल द्वारा नए के लिए तिरस्कार है। ORMs SQL में हैं क्योंकि C भाषा असेंबली में थी, और आप शर्त लगा सकते हैं कि C ++ और C # के समकक्ष उनके रास्ते में हैं। नए स्कूल कोड की एक पंक्ति पुराने स्कूल की 20 लाइनों के बराबर होती है।

Answer 10

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

मुझे लगता है कि यह संपूर्ण डेटा एक्सेस लेयर को कोड करने और ORM का उपयोग करने के बीच में है ...

Answer 11

व्यक्तिगत रूप से, मेरे पास (हाल ही में तक) एक ORM का उपयोग करने का विरोध किया है, और सभी SQL कमांडों को एनकैप्सुलेट करने वाली डेटा एक्सेस लेयर लिखकर प्राप्त करने के लिए उपयोग किया जाता है। ओआरएम पर मुख्य आपत्ति यह थी कि मुझे ओआरएम कार्यान्वयन पर बिल्कुल सही एसक्यूएल लिखने के लिए भरोसा नहीं था। और, ORMs को देखकर मैं (ज्यादातर PHP लाइब्रेरीज़) देखता था, मुझे लगता है कि मैं पूरी तरह से सही था।

अब, मेरे अधिकांश वेब विकास Django का उपयोग कर रहे हैं, और मुझे शामिल ORM वास्तव में सुविधाजनक लगा, और चूंकि डेटा मॉडल पहले उनकी शर्तों में व्यक्त किया गया है, और केवल बाद में SQL में, यह मेरी आवश्यकताओं के लिए पूरी तरह से काम करता है। मुझे यकीन है कि इसे उखाड़ फेंकना और हाथ से लिखी एसक्यूएल के साथ पूरक करने की आवश्यकता नहीं होगी; लेकिन CRUD के लिए उपयोग पर्याप्त से अधिक है।

मैं NHibernate के बारे में नहीं जानता; लेकिन मुझे लगता है कि यह भी आप की जरूरत के लिए "काफी अच्छा" है। लेकिन अगर अन्य कोडर्स इस पर भरोसा नहीं करते हैं; यह हर डेटा-संबंधित बग पर एक प्रमुख संदेह होगा, जिससे सत्यापन अधिक थकाऊ हो जाएगा।

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

Answer 12

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

Comments

क्या अापको उस बारे में पूर्ण विशवास है? ओएलटीपी ओआरएम के साथ अनुपयुक्त हैं क्योंकि ओएलएपी हैं (मेरा मतलब है, जटिलता के आधार पर)। इन दो चरम सीमाओं के बीच आवेदनों की एक विस्तृत श्रृंखला है, जिसके लिए एक ओआरएम एक अच्छा काम करता है। लेकिन OLAPs और OLTPs के लिए, वे एक बाधा बन सकते हैं।

— luis.espinal

Answer 13

मुझे लगता है कि ORM का उपयोग न करने के कई अच्छे कारण हैं। सबसे पहले और सबसे महत्वपूर्ण, मैं एक .NET डेवलपर हूं और मुझे यह पसंद है कि अद्भुत .NET फ्रेमवर्क मुझे पहले ही प्रदान कर चुका है। यह संभवतः वह सब कुछ करता है जिसकी मुझे आवश्यकता है। ऐसा करने से, आप एक अधिक मानक दृष्टिकोण के साथ बने रहते हैं, और इस प्रकार सड़क के नीचे एक ही प्रोजेक्ट पर काम करने वाले किसी भी अन्य डेवलपर के लिए बेहतर मौका है कि वह वहां क्या उठा सकता है और उसके साथ चल सकता है। Microsoft द्वारा पहले से उपलब्ध डेटा एक्सेस क्षमताएं काफी पर्याप्त हैं, उन्हें त्यागने का कोई कारण नहीं है।

मैं 10 वर्षों के लिए एक पेशेवर डेवलपर रहा हूं, कई बहुत सफल मिलियन + डॉलर परियोजनाओं का नेतृत्व करता हूं, और मैंने कभी भी एक आवेदन नहीं लिखा है जो किसी भी डेटाबेस पर स्विच करने में सक्षम होने की आवश्यकता है। आप कभी ऐसा क्यों करना चाहते हैं एक ग्राहक? सावधानी से योजना बनाएं, जो आपको चाहिए उसके लिए सही डेटाबेस चुनें, और इसके साथ रहें। व्यक्तिगत रूप से SQL सर्वर कुछ भी करने में सक्षम है जो मुझे कभी भी करने की आवश्यकता है। यह आसान है और यह बहुत अच्छा काम करता है। यहां तक ​​कि एक मुफ्त संस्करण भी है जो 10GB डेटा का समर्थन करता है। ओह, और यह .NET के साथ कमाल का काम करता है।

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

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

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

Comments

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

— डेविड

यह मजाकिया है। मैं 24 वर्षों के लिए एक डेवलपर रहा हूं और मैं कभी भी उस परियोजना में शामिल नहीं हुआ हूं जहां केवल एक आरडीबीएमएस विक्रेता का समर्थन करना संभव था। प्रत्येक परियोजना ने हमें कई RDBMS विक्रेताओं का समर्थन करने की आवश्यकता है, क्योंकि हमें उन ग्राहकों के साथ काम करने के लिए पर्याप्त लचीला होना चाहिए जो Oracle खोले हैं, और अन्य ग्राहकों के साथ काम करते हैं जो REQURE SQL Server काम करते हैं। यदि आप एक निर्वात में एक स्टोवपाइप एप्लिकेशन का निर्माण कर रहे हैं, तो हाँ आप बस RDBMS को निर्देशित कर सकते हैं। लेकिन मैं कभी भी ऐसी परियोजना में शामिल नहीं हुआ हूं जहां यह स्वीकार्य था।

— डेल्टमाइंड106 19

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

— जेफकन

Answer 14

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

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

Comments

मैं कुछ लोगों को यह कहते हुए याद करता हूं कि अनुकूलित क्वेरीज़ और डेटा लोड न करना कुछ स्थितियों में आवश्यक नहीं है (यानी जॉन्स का आलसी लोडिंग) वास्तव में चीजों को गति दे सकता है। मैन्युअल रूप से इसे कस्टम DAL में लागू करना अधिक काम और कम समय के लायक हो सकता है।

— हेंगी

Answer 15

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

पहली समस्या दो मुद्दों का कारण बनती है। आप बाहरी कोड पर भरोसा कर रहे हैं। हम सभी ऐसा करते हैं, लेकिन ऐसा करने का विकल्प हल्के में नहीं लिया जाना चाहिए। और क्या होगा अगर यह वह नहीं करता है जिसकी आपको आवश्यकता है? आप इसे कब खोजेंगे? आप उस बॉक्स के अंदर रहते हैं जिसे आपका ORM आपके लिए खींचता है।

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

Comments

उम्म ... यदि आप उपयोग कर रहे हैं, तो मान लें कि .NET, आप उनके कोड (जो आप संशोधित नहीं कर सकते हैं) पर निर्भर हैं। मैं यह नहीं देखता कि उदाहरण के लिए NHibernate के कोड पर निर्भर होने के मुकाबले यह कैसे अधिक "ठीक" है। पुस्तकालयों के अपभ्रंश होने के कारण आपने स्वयं नहीं लिखा है, अपेक्षाकृत हास्यास्पद है। ऐसा लगता है जैसे आप NIH से पीड़ित हैं

— जेसन बंटिंग

संकलक और वीएम सीएस का एक अपेक्षाकृत स्थिर हिस्सा है, और परीक्षणों के साथ बहुत मुश्किल नहीं है। ORM डिज़ाइन में 'थोड़ा ग़लत', या अपूर्ण दस्तावेज़ होने के कई तरीके हैं। यह सब कुछ संकलक के रूप में इतना बुनियादी पर भरोसा करना कठिन बनाता है।

— जेवियर

यह एक चेतावनी है ... कथन का उपयोग न करें। और यह तीन मुद्दों में से केवल एक चेतावनी है।

— डेराकोट

@dacracot: आप हर समय बहुत सारे विदेशी कोड पर भरोसा कर रहे हैं ... अपने ऑपरेटिंग सिस्टम से शुरू करते हैं, इसलिए मुझे नहीं लगता कि आपकी बात एक मान्य है। आशावादी लॉकिंग का उपयोग करके दूसरे बिंदु को कम किया जा सकता है, इसके अलावा दो-चरण की प्रतिबद्धताओं के साथ ऐसा करने के लिए बहुत कुछ नहीं है।

— एडम बर्टेक

कम परिपक्व ORM में से कुछ की बात करने पर dacracot स्पॉट-ऑन होता है। मुझे यकीन है कि कुछ रॉक बॉल्स हैं, लेकिन अधिकांश अपूर्ण होंगे, और यह कुछ (अधिकांश नहीं) वातावरणों में एक मुद्दा हो सकता है। दो चरण की प्रतिबद्धताओं के बारे में ... कोड में डीबी लेनदेन को मॉडल करने के तरीके हैं, लेकिन अप्रत्यक्ष की एक परत क्यों जोड़ते हैं जो कोई अमूर्तता प्रदान नहीं करता है?

— टॉम

Answer 16

मैं यह पढ़ने के लिए ORMs के डाउनसाइड्स की सूची के लिए सुझाव देता हूं।

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

अपने स्वयं के लिए, मैंने लिखा है कि अधिकांश अनुप्रयोगों के लिए ओआरएम बहुत उपयोगी है!

/ Asger

Answer 17

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

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

ओआरएम का उपयोग करने के लिए, किसी को वास्तव में इसे समझना चाहिए। दुर्भाग्य से किसी को आसानी से आभास हो जाता है कि यह आसान है जबकि ऐसा नहीं है।

Comments

हाइबरनेट UNION का समर्थन नहीं करता है? यह सेट सिद्धांत का एक बहुत ही मौलिक हिस्सा है! मुझे लगता है कि यह समस्या के बारे में सोचने का एक अलग तरीका बताता है।

— टॉम

Answer 18

प्रति उत्तर नहीं होना, मैं हाल ही में सुनाई गई बोली को फिर से लिखना चाहता हूं। "एक अच्छा ओआरएम एक यति की तरह है, हर कोई एक के बारे में बात करता है लेकिन कोई भी इसे नहीं देखता है।"

जब भी मैं अपने हाथों को ओआरएम पर रखता हूं, मैं आमतौर पर खुद को उस ओआरएम की समस्याओं / सीमाओं से जूझता हुआ पाता हूं। अंत में, हां यह वही करता है जो मैं चाहता हूं और यह उस घटिया दस्तावेज में कहीं लिखा गया था लेकिन मुझे लगता है कि मुझे एक और घंटे का नुकसान होगा जो मुझे कभी नहीं मिलेगा। कोई भी व्यक्ति जो nberberate का उपयोग करता है, तो postgresql पर धाराप्रवाह nhibernate समझ जाएगा कि मैंने क्या किया है। लगातार "यह कोड मेरे नियंत्रण में नहीं है" वास्तव में बेकार है।

मैं उँगलियों को इंगित नहीं करता या कहूँ कि वे खराब हैं, लेकिन मैंने यह सोचना शुरू कर दिया कि मैं एक अभिव्यक्ति में सिर्फ CRUD को स्वचालित करने के लिए क्या दे रहा हूं। आजकल मुझे लगता है कि मुझे ORM का कम उपयोग करना चाहिए, हो सकता है कि कोई ऐसा समाधान बनाएं या खोजें जो कम से कम db संचालन को सक्षम करता हो। लेकिन यह सिर्फ मैं हूं। मेरा मानना ​​है कि इस ORM क्षेत्र में कुछ चीजें गलत हैं लेकिन मैं इसे व्यक्त करने के लिए पर्याप्त कुशल नहीं हूं।

Comments

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

— १।

Answer 19

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

# 1 के लिए कोई तर्क नहीं है क्योंकि प्रश्नों को कॉपी और पेस्ट करना और पाठ में हार्डकॉडिंग करने से कोई लचीलापन नहीं मिलता है, और # 2 के लिए अधिकांश ऑरम मूल अपवाद को लपेटेंगे, उत्पन्न किए गए प्रश्नों आदि का पता लगाने की अनुमति देगा, इसलिए आइस रॉकेट विज्ञान को डीबग करना भी नहीं होगा।

सत्यापन के लिए, ORM का उपयोग करने से आमतौर पर सत्यापन रणनीतियों को विकसित करने में बहुत आसान समय मिलेगा, जो किसी भी सत्यापन में निर्मित शीर्ष पर होता है।

अपनी खुद की रूपरेखा लिखना श्रमसाध्य हो सकता है, और अक्सर चीजें छूट जाती हैं।

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

Answer 20

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

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

विशेष रूप से, जब आप मल्टी-कॉलम कीज़ या अन्य मामूली-जटिल रिश्तों को काम में लेते हैं, तो आप हिक्स में भाग लेने की संभावना रखते हैं, जो आपके द्वारा दिए गए आसान उदाहरणों के दायरे से बाहर आते हैं, जो आपके ORM ने आपको कोड डाउनलोड करते समय प्रदान किए थे।

मैं मानता हूं कि कुछ प्रकार के अनुप्रयोगों के लिए, विशेष रूप से जिनके पास डेटाबेस तालिकाओं की एक बहुत बड़ी संख्या है, या गतिशील रूप से उत्पन्न डेटाबेस तालिकाओं के लिए, कि ओआरएम की ऑटो-मैजिक प्रक्रिया उपयोगी हो सकती है।

अन्यथा, ORMs के साथ नरक करने के लिए। मैं अब उन्हें मूल रूप से सनक मानता हूं।