LINQ

Question

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

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

var customerOrderIds = table.Rows.Cast<DataRow>() 
    .Where(x => (string)x["CUSTOMER_ID"] == customerId) 
    .Select(x => (string)x["CUSTOMER_ORDER_ID"]) 
    .Distinct(); 

मेरा प्रश्न है या नहीं, यह एक अच्छी बात है, या कर रहा हूँ LINQ के साथ बह रही है? ऐसा लगता है कि संग्रह से डेटा का सबसेट खींचने की यह घोषणात्मक शैली एक अच्छी बात है और अंत में अधिक पठनीय है। लेकिन फिर, शायद मैं बस मार गया :)

Answer 1

एक अन्य अवलोकन; यदि आप टाइप डेटासेट उपयोग नहीं कर रहे हैं, आप भी Field<> विस्तार विधि के बारे में पता करने के लिए चाहते हो सकता है:

var customerOrderIds = table.Rows.Cast<DataRow>() 
     .Where(x => x.Field<string>("CUSTOMER_ID") == customerId) 
     .Select(x => x.Field<string>("CUSTOMER_ORDER_ID")) 
     .Distinct(); 

या क्वेरी सिंटेक्स के उपयोग:

var customerOrderIds = (
     from row in table.Rows.Cast<DataRow>() 
     where row.Field<string>("CUSTOMER_ID") == customerId 
     select row.Field<string>("CUSTOMER_ORDER_ID") 
    ).Distinct(); 

मैं यह नहीं कह रहा हूँ यह अच्छा है या है बदतर - बस एक और व्यवहार्य विकल्प।

(वास्तव में, मैं DataTable बहुत ज्यादा प्रयोग नहीं करते, YMMV तो)

Answer 2

मेरे लिए अच्छा लगता है - हालांकि मैं दृढ़ता से टाइप किए गए डेटा सेट का उपयोग करने की कोशिश करता हूं जो LINQ क्वेरी को और भी सुखद लगती है।

लेकिन हाँ, LINQ एक बहुत अच्छी बात है - और LINQ से ऑब्जेक्ट्स (और एक्सएमएल और डेटासेट्स के लिए आसपास की प्रौद्योगिकियां) प्रक्रिया के बाहर LINQ प्रदाताओं की तुलना में शानदार अनुमानित है। (यह कम सेक्सी LINQ से SQL तक, लेकिन अधिक व्यापक रूप से लागू आईएमओ है।)

Answer 3

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

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

Answer 4

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

Answer 5

LINQ बस आप के लिए "पाशन/अस्थायी चर" कोड लिख रहा है। LINQ आपको कोड को तेज़ी से लिखने में मदद करता है (और अधिक पठनीय)।

आप कोड अच्छे हैं।

Answer 6

क्वेरी ठीक दिखती है।

मैं दो छोटी चीजों को इंगित करना चाहता हूं।हे (एन) समाधान -

कोई पाशन

System.Linq.Enumerable तरीकों IEnumerable (टी) अनुबंध, जो लगभग हमेशा पाशन का मतलब के खिलाफ कार्य करते हैं। इसके दो प्रभाव:

• किसी भी() गणना()> 0 से अधिक पसंद करें। कोई भी() ओ (1) है। गणना() ओ (एन) है।
• शामिल हों ... सभी जॉइन नेस्टेड लूप ओ (एम * एन) हैं।

.Cast

.Cast DataTable.Rows (उन सभी वस्तुओं -are- पंक्तियों, इसलिए हमेशा डाली सफल होता है) के लिए महान काम करता है। विषम संग्रहों के लिए, ओफटाइप() - जो किसी भी आइटम को फ़िल्टर नहीं किया जा सकता है, से अवगत रहें।

आखिरकार, ध्यान रखें कि प्रश्नों को तब तक निष्पादित नहीं किया जाता जब तक उनका गणना नहीं किया जाता है! आप foreach, ToList, ToArray, पहले, एकल, और कई अन्य द्वारा गणना को मजबूर कर सकते हैं।

Answer 7

एक जुड़ें (शामिल कीवर्ड का उपयोग करके, लेकिन कीवर्ड से नहीं) मैचों के लिए एक शब्दकोश का उपयोग करता है और इस प्रकार O(M+N) है।

from x in Xs 
from y in Ys 
    .Where(o => o == x) 
select new 
{ 
    x, 
    y 
} 

जो O(M*N) है:

तो द्वारा एक समूह है, लेकिन नहीं पीछा कर रहा है।