ऑब्जेक्ट डेटासोर्स या कोड-बैक: कौन सा बेहतर है?

Question

मुझे पता है कि यह एक ऐसा विषय है जो बहुत बहस कर सकता है, लेकिन मैं जानना चाहता हूं कि लोग क्या सोचते हैं कि ऑब्जेक्ट डेटासेट का उपयोग करने के विभिन्न पेशेवरों और विपक्ष हैं। मैं अभी एक और प्रोग्रामर के साथ एक प्रोजेक्ट कर रहा हूं, जिसका अनुभव और आराम स्तर क्लासिक एएसपी में निहित है, और मुझे यकीन है कि
ए पर जा रहा है ए) नौकरी जल्दी से प्राप्त करें बी) काम पूरा करें कम से कम झगड़े

हमारे पास स्व-सत्यापन के लिए सक्षम डोमेन ऑब्जेक्ट्स के साथ एक अच्छी भंडार परत है, इसलिए ओडीएस बाध्यकारी या कोड-बैकिंग बाध्यकारी करने के लिए विधियां मौजूद हैं।

मैं स्पष्ट कारणों से ओडीएस को नापसंद करता हूं, लेकिन अगर यह मुझे हैंड-कोड पेजिंग/सॉर्टिंग/चयन/डालने/अपडेट करने/परिदृश्य हटाने से बचाता है, तो क्या यह वाकई खराब हो सकता है?

Answer 1

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

Answer 2

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

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

Answer 3

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

मैं कम से कम डाटाबेसिंग के जीवन चक्र से परिचित होने के लिए प्रशिक्षण पहियों के रूप में उन्हें कम या कम देखता हूं।

Answer 4

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

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

Answer 5

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

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

Answer 6

डेटासोर्सकंट्रोल का सबसे बड़ा लाभ यह है कि वे पूर्ण सीआरयूडी और दो-तरफा डाटाबेसिंग अभिव्यक्तियों के लिए समर्थन प्रदान करते हुए .NET जीवन चक्र के बारे में कई चिंताओं को दूर करते हैं, यानी।<% # बाइंड ("फर्स्टनाम")%> (हालांकि 2-तरफा डेटा-बाइंडिंग थोड़ी चूसती है ताकि आप शायद कुछ भी नहीं खो रहे हों)। एक डिजाइन पैटर्न के रूप में, यह एक मध्यम कार्यान्वयन के साथ एक बहुत अच्छा विचार है (वेबफॉर्म की तरह ही)।

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

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

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

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

http://mikeoff.blogspot.com/2006/06/objectdatasource-working-alternative.html

Answer 7

WebForms में ObjectDataSource किसी अन्य xxxDatasource जैसे बड़े एप्लिकेशन पर अपने व्यापार परत के बीच समन्वयक (डेटा एक्सेस परत: लेकिन इससे पहले कि मैं यह लिखा था कि मैं इस प्रयोग किया जाता है, जो ObjectDataSource के अपर्याप्तता से कुछ के लिए बनाता है छोटे पर) और खुद को नियंत्रित करता है।

यह आपके डेटा स्टोर में आपके विचारों द्वारा संचालित यूजर इंटरफेस, आपके एप्लिकेशन के दृश्य भाग के लिए डेटा और अन्य कार्यक्षमता प्रदान करता है।

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

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