2009-07-12 11 views
12

माइक्रोसॉफ्ट से बाहर आने वाली कई अलग-अलग डेटा एक्सेस रणनीतियों की प्रतीत होती है। 'क्लासिक' ADO.NET, Linq2Sql, ADO.NET इकाई फ्रेमवर्क, ADO.NET डेटा सेवा, ADO.NET गतिशील डेटा है। मुझे यकीन है कि मैंने कुछ याद किया है। मेरे लिए, ऐसा लगता है कि आस-पास बहुत भ्रम है जहां प्रत्येक ढांचे को एप्लिकेशन के आर्किटेक्चर में फिट किया जाता है। माइक्रोसॉफ्ट इन सभी डेटा एक्सेस विधियों के साथ हल करने का प्रयास कर रहा है?माइक्रोसॉफ्ट इन सभी डेटा एक्सेस रणनीतियों के साथ हल करने का प्रयास कर रहा है?

+0

आपको इसे एक समुदाय विकी प्रश्न बनाना चाहिए क्योंकि कोई निश्चित उत्तर नहीं है –

+1

अच्छा लगता है, धन्यवाद! –

+0

असल में, http://stackoverflow.com/questions/669242/ado-net-data-services-their-place-in-overall- डिज़ाइन और कई अन्य लोगों के डुप्लिकेट के रूप में बेहतर बंद हो जाएगा। –

उत्तर

5

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

+0

एमएस डीबी प्रौद्योगिकियों में कभी अच्छा नहीं रहा है: ओडीबीसी, ओएलडीडीबी, एडीओ, आरडीओ, डीएओ, जेट ... सूची में बहुत सारे हैं। – gbjbaanb

3

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

मेरी टीम निश्चित रूप से Linq2Sql द्वारा जला दिया गया।

अब हम एक डोमेन संचालित डिजाइन दृष्टिकोण और विशेष रूप से पालेर्मो के प्याज वास्तुकला (http://jeffreypalermo.com/blog/the-onion-architecture-part-1/) के साथ हमारी वेबसाइट का निर्माण करते हैं। व्यापार वस्तुएं केवल पीओसीओ हैं और बुनियादी ढांचे पर कोई निर्भरता नहीं है।

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

15

मुझे इस प्रश्न का मुद्दा नहीं दिख रहा है। वास्तव में, यह थोड़ा सा ट्रोलिश है।

  • ADO.NET .NET 1.0 से मूल डेटा एक्सेस तकनीक है। यह स्पष्ट रूप से नई डेटा पहुंच "रणनीतियों" की किसी भी चर्चा में शामिल नहीं है
  • LINQ से SQL मूल LINQ प्रदाताओं में से एक है। यह डेटाबेस संरचनाओं और प्रोग्राम में उपयोग किए जाने वाले प्रकारों के बीच एक-से-एक मैपिंग प्रदान करता है। यह SQL सर्वर
  • ADO.NET इकाई फ्रेमवर्क के साथ काम करने के लिए अधिक लचीला है। यह किसी भी ADO.NET प्रदाता के साथ काम करने के लिए था, और इसमें एक मैपिंग परत है, ताकि प्रोग्राम कक्षाओं के साथ काम करता है जो डेटाबेस टेबल की तुलना में व्यावसायिक संस्थाओं के करीब हैं। उदाहरण के लिए, एक इकाई में एकाधिक तालिकाओं से डेटा शामिल हो सकता है। माइक्रोसॉफ्ट ने LINQ से SQL पर ईएफ पर अधिक प्रयास करने का निर्णय लिया है।
  • ADO.NET डेटा सेवा ईएफ पर एक सेवा परत है। यदि आप अपने डेटा का पर्दाफाश करने के अलावा कुछ और करने के लिए अपनी सेवा का उत्पादन नहीं कर रहे थे, तो यह एक सभ्य शर्त है। यह एक आरईएसटी इंटरफेस का उपयोग करता है, और एटीओएम प्रारूप में डेटा का पर्दाफाश कर सकता है।
  • एएसपी.NET डायनामिक डेटा डेटा एक्सेस रणनीति नहीं है। http://www.asp.net/dynamicdata/ देखें।

भेद पर्याप्त स्पष्ट हैं कि अनुसंधान की एक छोटी राशि ने उन्हें स्पष्ट कर दिया होगा।

+4

भेद किसी ऐसे व्यक्ति के लिए बहुत स्पष्ट नहीं है जो किसी भी Microsoft उत्पादों का उपयोग नहीं करता है लेकिन उन उत्पादों के पीछे प्रौद्योगिकियों में सामान्य रुचि है। हम मौजूद हैं और इस तरह के दिलचस्प सवाल पर विचार कर सकते हैं। बिलकुल नहीं। – IlDan

+0

मैं मूल प्रश्न का जिक्र कर रहा था। शायद आप इसे अलग तरीके से शब्द होगा। –

3

उनके पास उम्र के लिए डेटा रणनीति है। वास्तव में आप "माइक्रोसॉफ्ट डेटा एक्सेस स्ट्रैटेजी" खोज सकते हैं और खोज सकते हैं और आपको लिंक पुराने और नए मिलेगा (यानी वर्ष 1 99 8 और उनकी ओएलडीडीबी रणनीति)।

मुझे लगता है कि आप जो खोज रहे हैं वह वर्ष 2007 से here है, भले ही 2 साल पुराना है एक्सएमएल, एडीओ.NET, डेटा, LINQ, SQL सर्वर, विजुअल स्टूडियो ऑर्कस, इकाई फ्रेमवर्क ... वे संबोधित करते हैं प्रश्न क्या माइक्रोसॉफ्ट के पास डेटा एक्सेस रणनीति है?:

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

माइक Pizzo, वास्तुकार, डाटा Programmability

मुझे आशा है कि यह मदद करता है।

1

यदि आप अंतर्निहित अवधारणाओं से परिचित नहीं हैं तो मुझे http://msdn.microsoft.com/en-us/magazine/cc700331.aspx पर लेख आलेख फ्रेमवर्क के लिए एक अच्छा तकनीकी परिचय मिल गया है।

यहाँ एक अनुभाग है कि इस सवाल का एफई के लक्ष्यों और ADO.Net के संबंध में से कुछ समझा के लिए प्रासंगिक है ...

ADO.NET इकाई की रूपरेखा ADO.NET का विकास और पहला है ईडीएम का ठोस कार्यान्वयन, एक संबंधपरक डेटाबेस के खिलाफ विकास करते समय उच्च स्तर का अमूर्त प्रदान करता है। संस्करण 1.0 में, टीम केवल एक साधारण ओआरएम से अधिक प्लेटफॉर्म की नींव बनाने पर केंद्रित है, जो डेवलपर्स को एक बहुत ही लचीली मैपिंग और उच्च डिग्री को समायोजित करने की क्षमता के साथ एक वैचारिक या ऑब्जेक्ट मॉडल के खिलाफ काम करने की अनुमति देगी अंतर्निहित स्टोर से विचलन का।

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

एडीओ.NET प्लेटफार्म विकसित करना शुरू करने के लिए, इकाई फ्रेमवर्क मौजूदा एडीओ.NET 2.0 प्रदाता मॉडल के शीर्ष पर बनाया गया है, मौजूदा प्रदाताओं को नए एंटिटी फ्रेमवर्क और एडीओ.NET 3.5 कार्यक्षमता का समर्थन करने के लिए थोड़ा अपडेट किया जा रहा है। हमने विकास समुदाय से परिचित एक प्रदाता मॉडल सुनिश्चित करने के लिए मौजूदा ADO.NET प्रदाता मॉडल के शीर्ष पर लागू करना चुना है।

संबंधित मुद्दे