ऐसा क्यों है कि एमएस डेटा एक्सेस कहानी इतनी फ्रैक्चर है? क्या यह डेटा एक्सेस की प्रकृति है या सिर्फ MS है?

11

यह StackOverflow प्रश्न पूछता है "मुझे Microsoft.Data.Objects कहाँ मिल सकता है"

यह पता चला है कि शायद यह संभवत: CTP4 (कोड पहले) में एंटिटी फ्रेमवर्क 4 की रिलीज थी, लेकिन जहां बहुत अधिक अनुमान था। समेत

System.Data
इकाई की रूपरेखा
Microsoft.ApplicationBlocks.Data
Microsoft.Practices.EnterpriseLibrary.Data

10 साल पहले अगर कोई उनसे इसी तरह का सवाल पूछता है तो उन्हें DAO, RDO, ADO मिल सकते हैं।

क्या यह सिर्फ जानवर की प्रकृति है या यह एमएस है।

क्या यह पैटर्न अन्य विक्रेताओं के साथ होता है? जहां आधार डेटा एक्सेस रणनीति या तो लपेटी गई है या बदल दी गई है?

data-structures microsoft-access

— कॉनराड फ्रैक्स
स्रोत

11

यह ऐतिहासिक / विकासवादी और बाजार बल कारणों का एक संयोजन है

कुछ साल पहले माइक्रोसॉफ्ट में काम करते समय, यह स्पष्ट था कि विकास में कई अलग-अलग डेटा प्रसाद थे। प्रत्येक प्रसाद को एक विशेष बाजार या उपयोग के मामले में लक्षित किया गया था, जैसे:

एक्सेस का उद्देश्य डेस्कटॉप उपयोगकर्ताओं को कार्ड इंडेक्सिंग सिस्टम के साथ सहज करना था जो फॉर्म और रिपोर्ट का उपयोग करके एप्लिकेशन बना सकते थे। SQL एक प्राकृतिक जोड़ था। यह सभी अपने स्वयं के 'JET' नामक स्थानीय-मशीन डेटाबेस इंजन का उपयोग करते थे। आखिरकार JET को दरकिनार कर दिया गया - अंगूर की बेल पर यह शब्द था कि (विश्वसनीय) स्रोत नियंत्रण की कमी का मतलब है कि वे स्रोत का एक बड़ा हिस्सा खो देंगे ।
फॉक्सप्रो का लक्ष्य डेस्कटॉप उपयोगकर्ताओं से था जो संबंधपरक डेटा पर गति चाहते थे।
SQL सर्वर एंटरप्राइज़ / सर्वर-साइड 'बिग' डेटाबेस सिस्टम था जिसमें सभी पैमाने / शक्ति / उपलब्धता, आदि की आवश्यकता होती है। IIRC, MS ने Sybase 6 के एक संस्करण को लाइसेंस दिया, जिस पर MSSQL का निर्माण किया गया।

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

इसलिए यह हमें Microsoft द्वारा निर्मित 3 'बैक एंड' - डेटाबेस उत्पाद देता है।

मिश्रण में जोड़ने के लिए, इन प्रणालियों तक पहुँच प्राप्त करने के लिए डेवलपर एपीआई के विभिन्न स्तर उपलब्ध थे:

प्रारंभ में, एपीआई के रास्ते में बहुत कुछ नहीं था - आपने एप्लिकेशन (फॉक्सप्रो / एक्सेस) के अंदर अपना कोड लिखा था। VBA एक तरीका था।
Microsoft ने MS ODBC को प्रतिस्पर्धी प्रणालियों से जोड़ने के लिए कार्यान्वित किया ताकि Windows Oracle, Sybase, आदि जैसे बड़े डेटाबेस से बात कर सके। ODBC उपकरण प्राप्त करने के लिए एक्सेल एक उल्लेखनीय ऐप था - अपने बड़े DB से डेटा खींचें, इसे हेरफेर करें और उत्पाद चार्ट / रेखांकन, आदि कई डेटाबेस विक्रेताओं ने ODBC को लागू करने के लिए समाप्त कर दिया ताकि ग्राहकों को जोड़ने की अनुमति दी जा सके, इसलिए यह रणनीति सफल रही .. एक हद तक - ODBC को सबसे कम आम भाजक का प्रतिनिधित्व करने के रूप में माना जा सकता है।
विभिन्न टीमों ने वीबी के माध्यम से रिमोट के लिए स्थानीय और आरडीओ (रिमोट डेटा ऑब्जेक्ट्स) के लिए डीएओ (डेटा एक्सेस ऑब्जेक्ट्स) जैसे डेटाबेस इंजन तक पहुंचने के अपने तरीके का उत्पादन करना शुरू कर दिया, जो उस समय सबसे लोकप्रिय एमएस डेवलपर उत्पाद था।
इन विविध एपीआई को युक्तिसंगत बनाने और एकल / एकीकृत अत्यधिक लचीले डेटाबेस एक्सेस एपीआई प्रदान करने के लिए एक आंतरिक प्रयास ने हमें OLEDB दिया, लेकिन इसमें बहुत सी (बहुत सारे C ++ टेम्पलेट) प्राप्त करना बहुत कठिन था।
OLEDB का उपयोग VB से नहीं किया जा सकता है, इसलिए ADO को ActiveX तकनीकों का उपयोग करके विकसित किया गया था, इसलिए यह COM / OLE / ActiveX, जिसका अर्थ एक्सेस, एक्सेल, VB और कुछ भी कर सकता है, के द्वारा पुन: प्रयोज्य बन गया और इसलिए ASP डेटाबेस-सक्षम हो गया।
जैसा कि हम .NET युग में चले गए, ADO स्वाभाविक रूप से एक .NET वातावरण में चला गया, जो विभिन्न लाभों को लाया।
LINQ के आगमन के साथ, वास्तविक डेटाबेस एक्सेस तंत्र एक समस्या से कम हो गया।

कैविएट - मैंने कुछ समय पहले छोड़ दिया है, इसलिए मेरी स्मृति थोड़ी फजी है

— JBRWilkinson
स्रोत

+1 DAO, RDO, ADO भाग की अच्छी व्याख्या, लेकिन यह सवाल बना हुआ है कि पैटर्न क्यों दोहराया गया?

— कॉनराड फ्रैक्स

मैंने हमेशा सोचा था कि यह अलग-अलग एमएस विभाग अपनी (एनआईएच) प्रौद्योगिकियों के साथ आ रहे थे। वहाँ निश्चित रूप से उनमें से एक बड़ी संख्या है और आप LINQ2SQL भूल गए, क्योंकि EF द्वारा प्रतिस्थापित किया गया है!

— gbjbaanb

5

आपके द्वारा उल्लेखित सभी उचित होने के लिए ADO.NET के शीर्ष पर बनाए गए हैं। इससे पहले कि ADO कुछ समय के लिए पसंदीदा मार्ग था, लेकिन DAO सिर्फ इस तरह से लटका रहता है क्योंकि यह Microsoft Access डेटाबेस के लिए मूल था। मैं जो बता सकता हूं उससे आने पर आरडीओ मर चुका था।

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

यह मुद्दा भी है कि एमएस एक बहुत बड़ी कंपनी है जिसमें विभिन्न एजेंडा वाली अलग-अलग टीमें हैं। उदाहरण के लिए उनके पास 3 शब्द प्रोसेसर क्यों हैं (जो मुझे पता है)।

— क्रेग
स्रोत

इस। ऐसा कोई भी नहीं है जो हर किसी पर सूट करता हो इसलिए वे सभी विकल्पों को खुला रखने की कोशिश करते हैं।

— १०

2

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

— JohnFx
स्रोत

4

फायर एंड मोशन

— मेसन व्हीलर

0

यह आईटी की प्रकृति है! चीज़ें बदल जाती हैं! जावा की दुनिया में, उनके पास एक ही चीज थी ... जेडडीबीसी, ईजेबी 1.0, ईजेबी 2.0, हाइबरनेट, ईजेबी 3.0 और इसी तरह।

— LeWoody
स्रोत

1

मैं जावा विशेषज्ञ नहीं हूं, लेकिन हाइबरनेट सूर्य से नहीं है, इसलिए इसकी तुलना नहीं है जिसकी मुझे तलाश थी। EJB SOA तब डेटा एक्सेस के बारे में अधिक लगता है, जो एक सॉफ्टवेयर स्टैक के अधिक है। सॉफ्टवेयर स्टैक मुझे मिलता है। एकीकरण के बिना एक ही काम करने के कई अलग-अलग तरीकों से ऐसा लगता है कि क्या दृष्टिकोण चिपक जाता है।

— कॉनरैड फ्राई