ORM रणनीति (.NET) चुनना

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

मैं तुरंत ध्यान देता हूं कि 99.9% समय आपको सीधे ADO.NET का उपयोग नहीं करना चाहिए। यदि आप अभी भी dataReader.MoveNext का उपयोग कर रहे हैं - dataReader.MoveNext !

बहुत से लोग ORM को पसंद नहीं करते हैं। उनके तर्क को सुनने के बाद, मैं सहमत हूं कि मार्टिन फाउलर ने ऑर्महेट में लिखा था:

ORM से सबसे बड़ी निराशा उच्च उम्मीदों में है ।

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

खाई को पाटना

यदि आपको एसक्यूएल में डेटा लोड या एम्बेड करना होगा, तो आपको एसक्यूएल में अपने .NET डेटा प्रकारों को मैप ("मैप") करना होगा। .NET के लिए, इसका मतलब SQL सर्वर पर SQL कमांड भेजने के लिए ADO.NET का उपयोग करना है। फिर हमें SQL प्रकारों को .NET प्रकारों पर मैप करने की आवश्यकता है। और बारीकियां हैं - उदाहरण के लिए, SQL में दिनांक .NET में दिनांक से भिन्न हैं।

ADO.NET इसकी मदद करता है, लेकिन हमें कच्चे डेटा सेट को संसाधित करने और .NET ऑब्जेक्ट बनाने का काम छोड़ देता है। अंत में, हमें वह मिलता है जो हम चाहते हैं - हम वस्तुओं और .NET प्रकारों के साथ काम करते हैं। और कुछ कोड इसे SQL प्रश्नों और इसके विपरीत में अनुवाद करते हैं।

ORMs को ADO.NET के शीर्ष पर विभिन्न सार की परतों को जोड़कर इस समस्या को हल करने के लिए डिज़ाइन किया गया है। लेकिन इसके लिए कई रणनीतियां हैं। आइए उनमें से प्रत्येक पर एक नज़र डालें और देखें कि कौन से सबसे अच्छे हैं।

इकाई आधारित संबंधपरक मानचित्रण

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

इस मामले में ORM बहुत अधिक कार्यक्षमता प्रदान करता है, उदाहरण के लिए:

• ट्रैकिंग बदलें
• आलसी लोडिंग (आलसी लोडिंग)
• प्रीलोड (उत्सुक लाने वाला)
• कास्केड
• वस्तुओं की विशिष्टता सुनिश्चित करना ( पहचान मानचित्र )
• काम की इकाइयों के साथ काम करें (काम की इकाई )

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

जब तक हम इसे बदलने के एकमात्र उद्देश्य के लिए Id द्वारा ऑब्जेक्ट को लोड करते हैं, यह सब ठीक काम करता है। इससे बड़ी मात्रा में कोड समाप्त हो जाते हैं जो मुझे वस्तुओं को जोड़ने, उन्हें बचाने, आदि का ट्रैक रखने के लिए बनाने की आवश्यकता होगी।

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

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

डेटासेट पर मैपिंग (परिणाम-सेट-आधारित रिलेशनल मैपिंग)

अधिकांश अनुप्रयोगों में, डेटा रीडिंग आवश्यकताएं रिकॉर्ड की संख्या से अधिक होती हैं। हमने अपने हालिया आवेदन में SELECT और INSERT / UPDATE / DELETE के बीच 100: 1 अनुपात देखा। जब हम देखते हैं कि एसक्यूएल वास्तव में क्या अच्छा है, तो यह सेट (सेट) में डेटा के साथ काम कर रहा है। SQL सर्वर से सेट किए गए डेटा का चयन करने के लिए, अक्सर इस डेटा को संस्थाओं में सीधे मैप करने की कोशिश करने का कोई मतलब नहीं होता है।

लेकिन हम अभी भी सीधे IDataReader या DataTable के साथ काम नहीं करना पसंद करते हैं। ये खराब टाइप की हुई वस्तुएं हैं जो एप्लिकेशन की ऊपरी परतों में स्थानांतरित करना मुश्किल है। इसके विपरीत, हम अक्सर डेटा के लिए अनुकूलित वस्तुओं का निर्माण करते हैं। इन ऑब्जेक्ट्स को अक्सर डीटीओ (डेटा-ट्रांसफर ऑब्जेक्ट्स), या रीड मॉडल कहा जाता है। हम व्यक्तिगत SQL नमूनों के लिए ऐसे डीटीओ बनाते हैं - और शायद ही कभी उन्हें अन्य प्रश्नों में पुन: उपयोग करने के लिए।

कई ओआरएम में ऐसे परिदृश्यों के लिए अनुकूलित विशेषताएं हैं। NHibernate में, आप ट्रैकिंग को बंद करने और सीधे DTO में डेटा प्रदर्शित करने के लिए अनुमानों का उपयोग कर सकते हैं। आप ऐसा करने के लिए SQL क्वेरी का उपयोग कर सकते हैं और मैपिंग कॉन्फ़िगरेशन की आवश्यकता नहीं है। या आप पेटाको की तरह माइक्रो-ओआरएम का उपयोग कर सकते हैं।

ये रीड्स डीटीओ ऑब्जेक्ट को भी पढ़ सकते हैं जैसा कि वे पढ़ते हैं। NHibernate और कई माइक्रो-ओआरएम दोनों आपको क्वेरी परिणाम पंक्तियों को पढ़ते हुए व्यक्तिगत डीटीओ ऑब्जेक्ट को क्रमिक रूप से एक-एक करके प्राप्त करने की अनुमति देते हैं, जिससे मेमोरी में निहित वस्तुओं की मात्रा कम हो जाती है।

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

सक्रिय रिकॉर्ड डेटा के आवश्यक प्रदर्शन का एक और उदाहरण है जिसमें डेटा के साथ काम करने की कार्यक्षमता ऑब्जेक्ट मॉडल में ही शामिल है।

डीएमएल-आधारित रिलेशनल मैपिंग

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

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

थोक लोडिंग उपकरण

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

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

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

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

कार्य के लिए सही उपकरण

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

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

SQL सर्वर के बाहर लिखा गया प्रत्येक एप्लिकेशन ORM का उपयोग करता है। या तो यह हस्तलिखित ADO.NET कोड, या NHibernate - आपको .NET और SQL के बीच के अंतर को पाटना होगा। यह काबू करना एक मुश्किल काम है, और कुछ भी समस्या को पूरी तरह से हल नहीं करता है। और यह नहीं करना चाहिए!

एक दृष्टिकोण चुनें जो एक विशिष्ट समस्या को हल करता है। चिंता न करें कि आपके पास एक परियोजना में कई ओआरएम रणनीतियां होंगी। इसका मतलब यह नहीं है कि सिस्टमेटिक समाधान स्वीकार्य हैं। लेकिन इसके विपरीत - संभावित विकल्पों के ज्ञान के आधार पर सत्यापित समाधानों का आवेदन हमेशा एक अच्छा विचार है।