"माइक्रो-ओआरएम" के कुछ लाभ क्या हैं?

Question

मैं डैपर की तरह तथाकथित "माइक्रो ओआरएम" में देख रहा हूं और (कुछ हद तक यह .NET 4.0 पर निर्भर है) बड़े पैमाने पर क्योंकि ये हमारे वर्तमान सिस्टम के बाद से पूर्ण-पूर्ण ORM की तुलना में काम पर लागू करना आसान हो सकता है। संग्रहीत प्रक्रियाओं पर अत्यधिक निर्भर है और इसे NHibernate या EF जैसे ORM के साथ काम करने के लिए महत्वपूर्ण रिफैक्टिंग की आवश्यकता होगी। एक पूर्ण विशेषताओं वाले ORM में से किसी एक का उपयोग करने का क्या लाभ है? यह एक डेटाबेस कनेक्शन चारों ओर सिर्फ एक पतली परत है कि अभी भी बलों आप कच्चे एसक्यूएल लिखने के लिए की तरह लगता है - शायद मैं गलत हूँ लेकिन मैं हमेशा ORMs के लिए कारण बताया गया था, ताकि आप नहीं किया था में पहले स्थान पर है है , यह एसक्यूएल लिखने के लिए अपने आप उत्पन्न हो सकता है; विशेष रूप से मल्टी-टेबल जॉइन के लिए और रिश्तों को मैप करने के लिए जो शुद्ध एसक्यूएल में एक ओआरएम के साथ तुच्छ होने का दर्द है।

उदाहरण के लिए, डापर का एक उदाहरण देख रहे हैं:

var connection = new SqlConnection(); // setup here...
var person = connection.Query<Person>("select * from people where PersonId = @personId", new { PersonId = 42 });

यह कैसे एक नियंत्रित ADO.NET डेटा लेयर का उपयोग करने से अलग है, सिवाय इसके कि आपको कमांड लिखना नहीं है, पैरामीटर सेट करें और मुझे लगता है कि बिल्डर का उपयोग करके यूनिट को वापस मैप करें। ऐसा लगता है कि आप SQL स्ट्रिंग के रूप में संग्रहीत कार्यविधि कॉल का भी उपयोग कर सकते हैं।

क्या अन्य मूर्त लाभ हैं जो मुझे याद आ रहे हैं जहाँ एक माइक्रो ओआरएम उपयोग करने के लिए समझ में आता है? मैं वास्तव में यह नहीं देख रहा हूं कि कोड के कुछ पंक्तियों को छोड़कर ADO.NET का उपयोग करने के "पुराने" तरीके पर यह कुछ भी कैसे बचा रहा है - आपको अभी भी यह पता लगाने के लिए लिखना होगा कि आपको किस एसक्यूएल को निष्पादित करने की आवश्यकता है (जो बालों को प्राप्त कर सकते हैं) और आपको अभी भी तालिकाओं के बीच रिश्तों को मैप करना है (वह भाग जो IMHO ORM सबसे अधिक मदद करता है)।

Comments

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

— स्टीवन एवर्स

हाँ, मैं डैपर का एक ठोस उदाहरण नहीं पा सका, इसके लिए साइट पर यह शाब्दिक रूप से करता है var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", new { Age = (int?)null, Id = guid });और फिर dog.First().Ageगुणों तक पहुँचने के लिए।

— वेन मोलिना

उदाहरण एक अनाम प्रकार नहीं लौटाता है, अतिरिक्त टाइपिंग को बचाने के लिए "var" कीवर्ड का उपयोग C # में एक ठोस प्रकार के स्थान पर किया जा सकता है, यह क्वेरी IEnumerable <Person> लौटाएगा।

— एड जेम्स

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

— वेन मोलिना

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

— एड जेम्स १

Answer 1

लाभ:

• DataReader और पार्सिंग के साथ कच्चे SqlCommand के समान प्रदर्शन।
• DataReader के लिए अपनी स्वयं की रूपांतरण परत को रोल करने की आवश्यकता नहीं है।

ईमानदार होने के लिए यह बहुत ज्यादा है। आपको अपने sql कनेक्शन के लिए एक बहुत हल्का आवरण मिला है जो आपके लिए ऑब्जेक्ट रूपांतरण करेगा। आप स्पष्ट रूप से किसी भी ऑटोजेनरेटेड एसक्यूएल से निपटने के बिना प्रश्नों को ठीक कर सकते हैं।

विपक्ष:

• थोड़ा टाइपफ भी नहीं। यदि आप SQL में टाइपो बनाते हैं तो आपका CI सर्वर इसे पकड़ने वाला नहीं है, आपको यह आशा करनी होगी कि यह स्वचालित UI या फ़ंक्शनल टेस्टिंग के दौरान पकड़ा जाएगा।
• बनाए रखने के लिए एक दर्द। आपको इनलाइन SQL कथनों का एक गुच्छा मिला है जो विभिन्न प्रश्नों को करते हैं जिनका DB वास्तुकला से कोई मजबूत संबंध नहीं है। यह आसानी से उन प्रश्नों को जन्म दे सकता है जो अंतर्निहित डीबी संरचना में परिवर्तन होने पर "पीछे छूट जाते हैं", जो, फिर से, आप बिल्ड समय पर नहीं देखेंगे।

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

यदि आप DB प्रश्नों पर प्रदर्शन के साथ संघर्ष कर रहे हैं, तो मेरा सुझाव है कि इन मैपिंग रूपरेखाओं का उपयोग केवल संग्रहीत कार्यविधियों के साथ करना बेहतर होगा, ताकि आपका एसक्यूएल वैध हो (अतिरिक्त प्रदर्शन लाभ) ।

Comments

ऐसे पुस्तकालय हैं जो इन माइक्रो ऑर्म्स के लिए एक आवरण के रूप में उपयोग किए जा सकते हैं जो कि टाइपो के साथ आपके द्वारा बताई गई समस्या को कम कर सकते हैं। उदा: डापर के लिए सरल क्रूड ऐड

— श्रीवत्स हरीश वेंकटरमना

Answer 2

माइक्रो ओआरएम पेटाको की वेबसाइट में वह अन्य ओआरएम के साथ कुछ लाभ की व्याख्या करता है। अधिक समझाने के लिए

पेटाकोको .NET और मोनो के लिए एक छोटा, तेज, सिंगल-फाइल माइक्रो-ओआरएम है।

• मैसिव की तरह यह एक सिंगल फाइल है जिसे आप आसानी से किसी भी प्रोजेक्ट में जोड़ सकते हैं
• बड़े पैमाने पर इसके विपरीत यह दृढ़ता से टाइप किए गए POCO के साथ काम करता है
• बड़े पैमाने की तरह, यह अब डायनेमिक एक्सपेंडेसो का भी समर्थन करता है - अधिक पढ़ें
• ActiveRecord की तरह, यह ऑब्जेक्ट और डेटाबेस टेबल के बीच घनिष्ठ संबंध का समर्थन करता है
• सबसोनिक की तरह, यह T4 टेम्प्लेट के साथ पोको वर्गों की पीढ़ी का समर्थन करता है
• डॅपर की तरह, यह तेज़ है क्योंकि यह गुणों के लिए स्तंभ मान असाइन करने के लिए डायनेमिक विधि उत्पादन (MSIL) का उपयोग करता है

Answer 3

यह कैसे एक नियंत्रित ADO.NET डेटा परत का उपयोग करने से अलग है, सिवाय इसके कि आपको कमांड लिखने की ज़रूरत नहीं है, पैरामीटर सेट करें और मुझे लगता है कि बिल्डर का उपयोग करके इकाई को मैप करें। ऐसा लगता है कि आप SQL स्ट्रिंग के रूप में संग्रहीत कार्यविधि कॉल का भी उपयोग कर सकते हैं।

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