ओ/आर मैपर - अच्छा या बुरा

Question

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

Answer 1

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

Answer 2

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

Answer 3

यह पहली बार एक असंबंधित उत्तर की तरह प्रतीत होता है, लेकिन: मेरी ओर से एक पक्ष WWII-era लड़ाकू विमान है। सभी लड़ाकू राष्ट्रों (यूएस, ग्रेट ब्रिटेन, जर्मनी, यूएसएसआर, जापान इत्यादि) ने युद्ध के दौरान विभिन्न सेनानियों का एक समूह बनाया। उनमें से कुछ रेडियल इंजन (पी 47, कॉर्सयर, एफडब्ल्यू -09, शून्य) का इस्तेमाल करते थे; कुछ इनलाइन तरल-ठंडा इंजन (बीएफ -109, मस्तंग, याक -7, स्पिटफायर) का इस्तेमाल करते थे; और कुछ ने एक (P38, Do-335) के बजाय दो इंजनों का उपयोग किया। कुछ मशीनों की बंदूकें, कुछ इस्तेमाल किए गए तोपों, और कुछ दोनों का इस्तेमाल किया जाता था। अगर आप कल्पना कर सकते हैं तो कुछ प्लाइवुड से भी बने थे।

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

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

Answer 4

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

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

जेरी

Answer 5

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

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

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

जैसा कि मैंने कहा था, मुख्य बात यह है कि किसी विशेष पद्धति के लिए अपने रंग पिन करने से पहले पेशेवरों और विपक्ष से अवगत रहें।

Answer 6

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

अब इस दृष्टिकोण का विपक्ष आमतौर पर समझने की कमी में है कि चीजें बहुत कम स्तर पर कैसे काम करती हैं। सबसे क्लासिक समस्या "चयन एन + 1" (link) है।

मैं अब 2.5 साल के लिए NHibernate के साथ काम कर रहा है, और मैं अभी भी लगभग एक दैनिक आधार पर कुछ इसके बारे में नई खोज कर रहा हूँ ...

Answer 7

अच्छा। अधिकतर परिस्थितियों में।

ओआरएम का उपयोग करने के उत्पादकता लाभ, ज्यादातर मामलों में डेटा का उपयोग कैसे किया जाता है, इस पर नियंत्रण के नुकसान से अधिक होगा।

एमएसआईएल या असेंबली प्रोग्राम के लिए सी # से बचने वाले बहुत से लोग नहीं हैं, हालांकि इससे उन्हें अधिक नियंत्रण मिलेगा।

Answer 8

यह वास्तव में स्थिति पर निर्भर करता है।

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

• इसकी उच्च ब्लोट
• और अनावश्यक
• निष्पादित वहाँ तालिका मानचित्रण के लिए एक भारी वस्तु है
• अपनी नहीं सूखी कोड आप
  पर एक पर अपने आप को दोहराने के लिए

है, क्योंकि

ठीक है, कुछ ही हफ्तों के लिए वहाँ काम करने के बाद, मैंने देखा था कि:

• हम कई प्रश्नों कि लगभग समान थे, और समय की बहुत अगर वहाँ एक बग था, केवल एक मुट्ठी तय जायेगा
सामान्य टेबल प्रश्नों को कैश करने के बजाय
• , हम कई बार एक टेबल पढ़ना समाप्त कर देंगे।
• हम सभी जगहों पर अपने आप को दोहरा रहे थे
• हमारे पास कौशल स्तर के कई स्तर थे, इसलिए कुछ प्रश्न सबसे कुशलता से नहीं लिखे गए थे।

जब मैंने इनमें से अधिकांश को इंगित किया, तो उन्होंने एक "डीबीओ" लिखा क्योंकि यह इसे ओआरएम नहीं कहना चाहता था। उन्होंने एक को बाहर निकालने के बजाय स्क्रैच से लिखने का फैसला किया।

इसके अलावा, तर्कों में से बहुत से ओआरएम के अनुभव के खिलाफ अज्ञानता से आते हैं। मैंने जो भी ओआरएम देखा है, वह कस्टम प्रश्नों के लिए अनुमति देता है, और यहां तक ​​कि ओआरएम के सम्मेलनों का पालन करने के बाद भी, आप बहुत ही जटिल और विस्तृत प्रश्न लिख सकते हैं और आम तौर पर अधिक मानव पठनीय होते हैं। इसके अलावा, वे बहुत शुष्क होते हैं, आप उन्हें अपनी स्कीमा देते हैं, और वे रिश्ते मैपिंग के लिए बाकी को समझते हैं।

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