इकाई फ्रेमवर्क और LINQ से SQL - ब्याज का संघर्ष?

Question

मैं पिछले सप्ताह के लिए ब्लॉगोस्फीयर पर पढ़ रहा हूं कि लिंक से एसक्यूएल मर चुका है [और लंबे समय तक ईएफ और लिंक से इकाइयों तक रहते हैं]। लेकिन जब मैंने एमएसडीएन पर अवलोकन पढ़ा, तो मुझे लगता है कि लिंक से एंटिटीज ईएसक्यूएल उत्पन्न करता है जिस तरह लिंक से एसक्यूएल एसक्यूएल क्वेरी उत्पन्न करता है।

अब अंतर्निहित कार्यान्वयन (और चूंकि SQL सर्वर अभी तक एक ओडीबीएमएस नहीं है) अभी भी एक रिलेशनल स्टोर है, कुछ बिंदु पर इकाई ढांचे को SQL क्वेरी में अनुवाद करना है। लिंक को एसक्यूएल मुद्दों को ठीक क्यों नहीं करें (एम: एम रिश्तों, केवल एसक्यूएल सर्वर समर्थन इत्यादि) और इन प्रश्नों को उत्पन्न करने वाली परत के रूप में SQL से SQL का उपयोग करें?

क्या यह प्रदर्शन या ईएफ के कारण एसएसएल में ईएसक्यूएल कथन को बदलने का एक अलग तरीका उपयोग करता है?

यह मुझे लग रहा था - कम से कम मेरे अनजान दिमाग के लिए - डॉगफूड के लिए प्राकृतिक फिट ईएफ में लिंक से एसक्यूएल।

टिप्पणियां?

Answer 1

यह ध्यान देने योग्य है कि इकाई की रूपरेखा है लायक है (कम से कम) सेवन किया जा रहा के तीन तरीके: इकाई ग्राहक से अधिक वस्तु सेवा से अधिक इकाई ग्राहक से अधिक वस्तु सेवा से अधिक संस्थाओं

इकाई एसक्यूएल को

• LINQ
• इकाई एसक्यूएल इकाई ग्राहक आदेश वस्तुओं (क्लासिक ADO.NET के लिए सबसे समान) का उपयोग कर

इकाई ग्राहक अंततः (ESQL आदेश का प्रतिनिधित्व में बाहर थूक एक कैनोलिक, डेटाबेस अज्ञेयवादी रूप) जो विशिष्ट आरडीबीएमएस के लिए ADO.NET प्रदाता स्टोर विशिष्ट एसक्यूएल में परिवर्तित करने के लिए ज़िम्मेदार है। यह पिछले वर्षों में आईएमएचओ का सही मॉडल है, प्रत्येक स्टोर के लिए महान एडीओ.NET प्रदाता बनाने में काफी समय निवेश किया गया है (और निवेश जारी रहेगा)।

चूंकि इकाई फ्रेमवर्क को कई स्टोर्स के साथ काम करने की आवश्यकता है और इसलिए कई एडीओ.NET प्रदाता उनके लिए प्रति स्टोर आधार पर कम से कम अनुकूलित करने के लिए कम गुंजाइश है (कम से कम - जहां हम v1 के साथ हैं) । LINQ से SQL टीम को हल करने के लिए बहुत छोटी समस्या थी - "केवल SQL सर्वर के साथ काम करता है" और इसलिए स्टोर विशिष्ट सामग्री को अधिक आसानी से कर सकता था। मुझे पता है कि ईएफ टीम को पता है कि ऐसे मामले हैं जहां एसक्यूएल सर्वर के लिए ईएफ एल 2 एस की तुलना में टीएसक्यूएल कम कुशलता से उत्पादन कर रहा है और वी 2 के लिए इसे सुधारने पर काम कर रहा है।

दिलचस्प बात यह मॉडल एक इकाई के लिए इकाई ग्राहक और ADO.NET प्रदाता के बीच नई क्षमताओं को जोड़ने की अनुमति देता है। ये "रैपिंग प्रदाता" लॉगिंग, ऑडिटिंग, सुरक्षा, कैशिंग जैसी सेवाएं जोड़ सकते हैं। http://blogs.msdn.com/efdesign/archive/2008/07/09/transparent-caching-support-in-the-entity-framework.aspx

पर एक वी 2 फीचर के रूप में चर्चा की जाती है यदि आप बड़ी तस्वीर पर देखते हैं तो आप देख सकते हैं कि यह बहुत कठिन और वास्तव में प्रतिबंधित है और एल 2 एस टीएसक्यूएल पीढ़ी को एंटीटी फ्रेमवर्क की आर्चीचर में फिर से निकालने के लिए प्रतिबंधित होगा।

Answer 2

लिंक से एसक्यूएल और एंटिटी फ्रेमवर्क के बीच एक बड़ा अंतर यह है कि ईएफ एंटिटी डेटा मॉडल विनिर्देश (ईडीएम) लागू करता है, और ऐसे अन्य उत्पाद हैं जो ईडीएम के आसपास बनाए जाते हैं, जैसे एडीओ.NET डेटा सर्विसेज (उर्फ एस्टोरिया)।

ईडीएम अब ओपन डेटा प्रोटोकॉल (ओडाटा http://odata.org/) नामक एक नए spec में एटमप्यूब का विस्तार करने के लिए उपयोग किया जा रहा है, जिसका उपयोग आरईएसटी के शीर्ष पर सीआरयूडी को खड़ा करने के लिए किया जाता है।

Answer 3

असल में, ईएफ LINQ क्वेरीज़ का अनुवाद करते समय EntitySQL उत्पन्न नहीं करता है।ईएफ में हमारे पास सीक्यूटी या कैनोलिक क्वेरी पेड़ नामक सभी प्रश्नों के लिए डेटा संरचना-आधारित प्रतिनिधित्व है। LINQ अनुवादक और EntitySQL पार्सर दोनों सीक्यूटी का उत्पादन करते हैं, और बाकी क्वेरी अनुवाद पाइपलाइन सीक्यूटी (और अन्य आंतरिक इंटरमीडिएट फॉर्म) का उपयोग करती है, जो विभिन्न परिवर्तनों के बाद इसे ADO.NET प्रदाता (स्टोर-स्तर सीक्यूटी के रूप में) बनाती है, जो बैकएंड की एसक्यूएल बोली में अनुवाद करने के लिए जिम्मेदार है। तो पथ LINQ -> सीक्यूटी -> एसक्यूएल या EntitySQL -> सीक्यूटी -> एसक्यूएल हैं।