10 LINQ मिथक

मिथक # 1

सभी LINQ क्वेरी कीवर्ड 'var' से शुरू होनी चाहिए। अनिवार्य रूप से, 'var' कीवर्ड का मुख्य उद्देश्य LINQ क्वेरी शुरू करना है!

Var कीवर्ड और LINQ स्टैंडअलोन कॉन्सेप्ट हैं। Var कीवर्ड कंपाइलर को आरंभिक असाइनमेंट (अंतर्निहित टाइपिंग) के आधार पर स्थानीय चर के प्रकार का अनुमान लगाने की अनुमति देता है। उदाहरण के लिए, निम्न कोड:

var s = "Hello"; 

इसके लिए सटीक समकक्ष:

 string s = "Hello"; 

क्योंकि कंपाइलर स्ट्रिंग के रूप में चर के प्रकार को संक्रमित करता है।
इसी प्रकार, निम्नलिखित प्रश्न:

 string[] people = new [] { "Tom", "Dick", "Harry" }; var filteredPeople = people.Where (p => p.Length > 3); 

इसके लिए सटीक समकक्ष:

 string[] people = new [] { "Tom", "Dick", "Harry" }; IEnumerable<string> filteredPeople = people.Where (p => p.Length > 3); 

आप यह देख सकते हैं कि हमने जो कुछ भी var कीवर्ड के साथ हासिल किया था वह IEnumerable <string> का संक्षिप्त नाम बनाना था। बहुत से लोग इस रिकॉर्ड को पसंद करते हैं क्योंकि यह छोटा है; दूसरों का मानना ​​है कि निहित टाइपिंग कोड को कम समझने योग्य बना सकती है।

ऐसी परिस्थितियाँ हैं जिनमें LINQ प्रश्नों के लिए var कीवर्ड की आवश्यकता होती है । यह तब होता है जब एक अनाम प्रकार में अनुमानित किया जाता है :

 string[] people = new [] { "Tom", "Dick", "Harry" }; var filteredPeople = people.Select (p => new { Name = p, p.Length }); 

निम्न उदाहरण दिखाता है कि LINQ संदर्भ के बाहर एक अनाम प्रकार का उपयोग कैसे करें:

 var person = new { Name = "Foo", Length = 3 }; 

मिथक # 2

सभी LINQ क्वेरी क्वेरी सिंटैक्स का उपयोग करना चाहिए।

LINQ क्वेरी लिखने के दो तरीके हैं: लैम्ब्डा सिंटैक्स और क्वेरी सिंटैक्स ।

लैम्ब्डा सिंटेक्स उदाहरण:

 string[] people = new [] { "Tom", "Dick", "Harry" }; var filteredPeople = people.Where (p => p.Length > 3); 

पिछले एक के समान एक उदाहरण, लेकिन क्वेरी सिंटैक्स का उपयोग करना:

 string[] people = new [] { "Tom", "Dick", "Harry" }; var filteredPeople = from p in people where p.Length > 3 select p; 

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

सभी ऑपरेटर क्वेरी सिंटैक्स में उपलब्ध नहीं हैं, इसलिए इन दो प्रकार के सिंटैक्स एक दूसरे के पूरक होने की अधिक संभावना है। सभी से सर्वश्रेष्ठ प्राप्त करने के लिए, आप क्वेरी शैलियों को एक अभिव्यक्ति में मिला सकते हैं (मिथक # 5 देखें)।

मिथक # 3

सभी ग्राहकों को तालिका से निकालने के लिए, आपको इसके समान एक क्वेरी का उपयोग करना चाहिए:
var क्वेरी = c से db.Customers में c चुनें।

अभिव्यक्ति

 from c in db.Customers select c 

बहुत वाचाल है! आप बस का उपयोग कर सकते हैं:

 db.Customers 

इसी तरह, निम्न LINQ XML क्वेरी के लिए:

 var xe = from e in myXDocument.Descendants ("phone") select e; 

सरल किया जा सकता है:

 var xe = myXDocument.Descendants ("phone"); 

और यह अनुरोध:

 Customer customer = (from c in db.Customers where c.ID == 123 select c) .Single(); 

सरल किया जा सकता है:

 Customer customer = db.Customers.Single (c => c.ID == 123); 

मिथक # 4

LINQ में SQL क्वेरी को पुन: उत्पन्न करने के लिए, आपको LINQ क्वेरी को SQL क्वेरी के समान ही बनाना चाहिए।

LINQ और SQL अलग-अलग अवधारणाओं का उपयोग करने वाली अलग-अलग भाषाएं हैं।

शायद LINQ के उत्पादक उपयोग के लिए मुख्य बाधा "SQL शब्दों में सोचें" सिंड्रोम है: SQL में क्वेरी को मानसिक रूप से प्रस्तुत करें, और फिर इसे LINQ में अनुवाद करें। परिणाम एपीआई के साथ एक निरंतर संघर्ष होगा!

एक बार जब आप विशेष रूप से LINQ शब्दों में सोचना शुरू करते हैं , तो आपके प्रश्नों में उनके SQL समकक्षों के साथ बहुत कम समानता होगी। कई मामलों में, वे बहुत सरल भी होंगे।

मिथक # 5

LINQ में कुशल जॉइनिंग के लिए, आपको जॉइन कीवर्ड का उपयोग करना चाहिए।

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

इसके अलावा, LINQ to SQL और एंटिटी फ्रेमवर्क में, आप एसोसिएशन की संपत्तियों का अनुरोध कर सकते हैं जो जुड़ने की आवश्यकता को कम करती हैं! उदाहरण के लिए, निम्न कोड दिखाता है कि आप उन सभी ग्राहकों के नाम और पहचानकर्ता कैसे निकाल सकते हैं जिन्होंने एक भी खरीद नहीं की है:

 from c in db.Customers where !c.Purchases.Any() select new { c.ID, c.Name } 

या ऐसे ग्राहक निकालें जिन्होंने $ 1000 से अधिक की खरीदारी नहीं की है:

 from c in db.Customers where !c.Purchases.Any (p => p.Price > 1000) select new { c.ID, c.Name } 

ध्यान दें, हमने लैम्ब्डा सिंटैक्स और क्वेरी सिंटैक्स को मिलाया। एसोसिएशन के गुणों, कनेक्शन मार्गदर्शिकाओं और मिश्रित सिंटैक्स के अधिक उदाहरणों के लिए, LINQPad देखें।

मिथक # 6

चूंकि SQL क्वेरी का परिणाम एक फ्लैट डेटासेट है, LINQ क्वेरी बनाई जानी चाहिए ताकि वे एक फ्लैट डेटासेट भी लौटा सकें।

यह मिथक # 4 का एक कोश है। LINQ का एक मुख्य लाभ यह है कि आप कर सकते हैं:

1. एसोसिएशन गुणों (मैन्युअल रूप से कनेक्ट करने के बजाय) के माध्यम से एक संरचित वस्तु का अनुरोध करें;
2. ऑब्जेक्ट पदानुक्रम में सीधे प्रोजेक्ट करें।

सिद्धांत रूप में, 1 और 2 स्वतंत्र हैं, लेकिन 1 मदद करता है 2. उदाहरण के लिए, यदि आप WA ग्राहकों की संख्या उनकी खरीद के साथ पुनर्प्राप्त करना चाहते हैं, तो आप निम्नलिखित कोड का उपयोग कर सकते हैं:

 from c in db.Customers where c.State == "WA" select new { c.Name, c.Purchases // An EntitySet (collection) } 

इस क्वेरी का पदानुक्रमित परिणाम फ्लैट डेटासेट की तुलना में काम करने के लिए बहुत सरल है।

हम संघों के गुणों का उपयोग किए बिना एक ही परिणाम प्राप्त कर सकते हैं:

 from c in db.Customers where c.State == "WA" select new { c.Name, Purchases = db.Purchases.Where (p => p.CustomerID == c.ID) } 

मिथक # 7

LINQ to SQL में बाहरी जॉइन को लागू करने के लिए, आपको हमेशा DefaultIfEmpty () ऑपरेटर का उपयोग करना चाहिए।

यदि आपको एक फ्लैट डेटासेट की आवश्यकता है तो यह सच है। पिछले मिथक में उदाहरण एसक्यूएल में एक बाएं बाहरी में अनुवाद करता है और DefaultIfEmpty कथन की आवश्यकता नहीं है।

मिथक # 8

LINQ to SQL या एंटिटी फ्रेमवर्क क्वेरी केवल एक इकाई के रूप में चलेगी जब वे एक चरण में बनाए गए थे।

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

उदाहरण के लिए, निम्नलिखित क्वेरी उन सभी ग्राहकों के नामों को पुनः प्राप्त करती है, जिन्होंने दो खरीदारी की हैं, जिनका नाम 'A' अक्षर से शुरू होता है। हमने इस क्वेरी को तीन चरणों में बनाया है:

 var query = db.Customers.Where (c => c.Name.StartsWith ("A")); query = query.Where (c => c.Purchases.Count() >= 2); var result = query.Select (c => c.Name); foreach (string name in result) //     ! Console.WriteLine (name); 

मिथक # 9

यदि कोई विधि 'नए' ऑपरेटर के साथ समाप्त होती है, तो कोई अनुरोध वापस नहीं कर सकता।

चाल को एक प्रारंभिक संकलक का उपयोग करके एक नियमित नाम प्रकार में प्रोजेक्ट करना है:

 public IQueryable<NameDetails> GetCustomerNamesInState (string state) { return from c in Customer where c.State == state select new NameDetails { FirstName = c.FirstName, LastName = c.LastName }; } 

NameDetails वर्ग निम्नानुसार परिभाषित किया गया है:

 public class NameDetails { public string FirstName, LastName; } 

मिथ # 10

LINQ to SQL का उपयोग करने का सबसे अच्छा तरीका एक स्थिर संपत्ति में DataContext वर्ग के एकल उदाहरण को इंस्टेंट करना है और एप्लिकेशन के पूरे जीवन में इस साझा उदाहरण का उपयोग करना है।

इस तरह की रणनीति से अप्रचलित डेटा को बढ़ावा मिलेगा, क्योंकि अनुरोध दोहराए जाने पर DataContext इंस्टेंस द्वारा मॉनिटर की गई वस्तुओं को अपडेट नहीं किया जाता है।

DataContext वर्ग के एकल उदाहरण का उपयोग करने से आपको बहुत परेशानी होगी क्योंकि यह थ्रेड सुरक्षित नहीं है।

सही रणनीति वस्तुओं के लिए प्रत्येक अनुरोध के लिए डेटाकोटेक्स्ट का एक नया उदाहरण बनाना है, जिससे इसका जीवन काफी छोटा हो जाता है। वही एंटिटी फ्रेमवर्क के लिए जाता है।

इस लेख के अलावा, मैंने LINQ क्विज़ (परीक्षण) का भी अनुवाद किया, जिसे मैंने अपने ब्लॉग ( उत्तर ) पर पोस्ट किया था । मुझे लगता है कि जो अलबहारी द्वारा पूछे गए सवालों के जवाबों पर चर्चा करना बहुत उपयोगी और दिलचस्प होगा!