LINQ का उपयोग करके अपने आप को पैर में गोली न मारें

लेख में, मैंने SQL को LINQ का उपयोग करते समय गैर-स्पष्ट बिंदुओं के कुछ उदाहरणों का वर्णन किया। यदि आप एक .NET गुरु हैं, तो आपको यह उबाऊ लग सकता है, बाकी के लिए - स्वागत है!
आइए इस उदाहरण से शुरू करते हैं। मान लीजिए कि हमारे पास एक इकाई है "कार्रवाई का प्रकार।" एक क्रिया प्रकार में एक मानव-पढ़ने योग्य नाम और एक सिस्टम नाम है - एक अद्वितीय पहचानकर्ता जिसके द्वारा हम कोड से इस इकाई की वस्तुओं के साथ काम कर सकते हैं। यहाँ कोड में वस्तुओं के रूप में इस तरह की संरचना है:

class ActionType { public int id; public string systemname; public string name; } 

 var ActionTypes = new ActionType[] { new ActionType { id = 1, systemname = "Registration", name = "" }, new ActionType { id = 2, systemname = "LogOn", name = "  " }, new ActionType { id = 3, systemname = null, name = "     " } }; 

समान डेटा वाली समान संरचना के लिए, डेटाबेस और सहायक वस्तुओं में LINQ से SQL का उपयोग करने के लिए एक तालिका बनाई गई थी। मान लें कि हमें यह पता लगाना है कि क्या हमारे पास एक्शन टाइप NotExistingActionType है । सवाल यह है कि इन निर्देशों का पालन करने के बाद क्या प्रदर्शित किया जाएगा:

 var resultForObjects = ActionTypes.All(actionType => actionType.systemname != "NotExistingActionType"); var context = new LinqForHabr.DataClasses1DataContext(); var resultForLTS = context.ActionTypes.All(actionType => actionType.SystemName != "NotExistingActionType"); Console.WriteLine("Result for objects: " + resultForObjects + "\nResult for Linq to sql: " + resultForLTS); Console.ReadLine(); 

इस मामले में जवाब पहली नज़र में अजीब है। आवेदन का परिणाम होगा:

वस्तुओं के लिए परिणाम: सत्य
LINQ to sql का परिणाम: गलत

एक ही डेटा के लिए "समान विधि" अलग-अलग मान क्यों लौटाती है? बात यह है कि यह एक ही विधि नहीं है, बल्कि एक ही नाम के साथ अलग-अलग विधियां हैं। पहला मेमोरी में ऑब्जेक्ट्स पर निर्भर करता है, दूसरा एक SQL क्वेरी में बदल जाता है, जिसे सर्वर पर निष्पादित किया जाएगा और एक और परिणाम हमें लौटाएगा। परिणाम हमारे प्रकार के कार्यों के बीच एक अपरिभाषित सिस्टम नाम के साथ मौजूद होने के कारण भिन्न होते हैं। और इस समय, दो रनटाइम्स के विशिष्ट अंतर प्रकट होते हैं: .NET के लिए, अभिव्यक्ति null! = ObjRef सच है (जब तक कि objRef शून्य नहीं है ), और इसलिए हमारी स्थिति में सभी प्रकार के कार्यों के अभिव्यक्ति "सिस्टम नाम NotExistingActionType " के बराबर नहीं हैं।
लेकिन LINQ to SQL एक्सप्रेशन SQL में कनवर्ट किए जाते हैं और सर्वर पर निष्पादित होते हैं, और SQL में NULL की तुलना अलग तरीके से होती है। NULL == का मान , कुछ, NULL! = कुछ और यहां तक ​​कि NULL == पूर्ण अभिव्यक्ति हमेशा गलत होगी, यह मानक है, इसलिए "सभी प्रकार के कार्यों के सिस्टम नाम समान नहीं हैं NotExistingActionType " और सत्य नहीं होगा, क्योंकि NULL-= 'NotExistingActionType' -! एक झूठ।

अब एक और उदाहरण पर विचार करें। मान लें कि हमारे पास अपने वर्तमान शेष राशि वाले उपयोगकर्ता हैं:

 class User { public int id; public int balance; public string name; } 

 var users = new User[] { new User { id = 1, name = "", balance = 0 }, new User { id = 2, name = "", balance = 0 } }; 

सवाल यह है कि तत्वों के एक खाली सेट पर राशि क्या वापस आनी चाहिए। मेरे लिए, उदाहरण के लिए, स्पष्ट मान 0 है, लेकिन यहां भी, इतना सरल नहीं है। आइए कुछ इस तरह से करें:

 var resultForObjects = users.Where(user => user.id < 0).Sum(user => user.balance); var context = new LinqForHabr.DataClasses1DataContext(); var resultForLTS = context.Users.Where(user => user.Id < 0).Sum(user => user.Balance); Console.WriteLine("Result for objects: " + resultForObjects + "\nResult for Linq to sql: " + resultForLTS); Console.WriteLine(context.ActionTypes.First().Name); Console.ReadLine(); 

परिणाम फिर से असामान्य होगा। सामान्यतया, हम इन निर्देशों को इस रूप में निष्पादित नहीं कर पाएंगे, क्योंकि निष्पादन के दौरान एक अपवाद होगा:

System.InvalidOperationException: "NULL मान को उस सदस्य को नहीं सौंपा जा सकता है जो एक System.Int32 प्रकार है जो NULL मानों की अनुमति नहीं देता है।"

जो कुछ फिर से हो रहा है उसके कारण हमारे कॉल को SQL में अनुवाद कर रहे हैं। एक सामान्य IEnumerable एक्सटेंशन के लिए, Sum एक खाली सेट के लिए 0 देता है, जो परिणाम देखे बिना आसान है (अच्छी तरह से, या अंत में, इसे यहाँ पढ़ें msdn.microsoft.com/en-us/library/bb549046 )। हालाँकि, DBMS रिक्त सेट की राशि की गणना NULL के रूप में करता है (चाहे वह सही हो या नहीं - प्रश्न बहुत समग्र है, लेकिन अब यह सिर्फ एक तथ्य है), और LINQ, पूर्णांक के बजाय अशक्त लौटने की कोशिश कर रहा है, तुरंत विफल हो जाता है। इस जगह को ठीक करना बेहद आसान है, लेकिन नज़र रखें:

 var resultForLTS = context.Users.Where(user => user.Id < 0).Sum(user => (int?)user.Balance) ?? 0; 

यहाँ, सम फ़ंक्शन का रिटर्न मान अंतर नहीं है, लेकिन अशक्त इंट (यह स्पष्ट रूप से जेनेरिक प्रकार को निर्दिष्ट करके प्राप्त किया जा सकता है), जो LINQ को अशक्त करने में सक्षम बनाता है, लेकिन ?? इस शून्य को 0 में बदल देगा।

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

 class User { public int id; public int balance; public string name; public Location location; } class Location { public int id; public string Name; } 

हम कोई भी स्थान ऑब्जेक्ट नहीं बनाएंगे और उपयोगकर्ताओं को बदलेंगे, निम्नलिखित कोड रुचि का है:

 var resultForObjects = users.Select(user => user.location == null ? "  " : user.location.Name == null ? "  " : user.location.Name) .First(); var context = new LinqForHabr.DataClasses1DataContext(); var resultForLTS = context.Users.Select(user => user.Location == null ? "  " : user.Location.name == null ? "  " : user.Location.name) .First(); 

दोनों स्थितियों में, परिणाम "स्थान निर्दिष्ट नहीं" होगा, क्योंकि यह वास्तव में निर्दिष्ट नहीं है, लेकिन अगर आप इसे पसंद करते हैं तो क्या होगा:

 var resultForLTS = context.Users.Select(user => user.Location.name ?? "  "); 

आप सोच सकते हैं कि यह काम नहीं करेगा, क्योंकि एक स्पष्ट NullReferenceException है (किसी उपयोगकर्ता के पास कोई स्थान ऑब्जेक्ट एक प्राथमिकता नहीं है, हमने उन्हें नहीं बनाया, हमने उन्हें डेटाबेस में नहीं लिखा है), लेकिन हम यह नहीं भूलते हैं कि यह कोड पर्यावरण में नहीं चलाया जाएगा .NET, लेकिन SQL में अनुवादित किया जाएगा और DBMS लॉन्च किया जाएगा। वास्तव में, इस कोड से आने वाली क्वेरी इस तरह दिखाई देगी (LINQPad मदद करने के लिए):

 SELECT COALESCE([t1].[name],@p0) AS [value] FROM [Users] AS [t0] LEFT OUTER JOIN [Locations] AS [t1] ON [t1].[Id] = [t0].[LocationId] 

यह "ट्रिक" हमें LINQ प्रश्नों में जंगली संख्या में टर्नरी ऑपरेटरों को लिखने की अनुमति नहीं देता है।

निष्कर्ष:

जब हम कोड लिखते हैं, तो हम लगातार निचले स्तर के कार्यों पर भरोसा करते हैं और मानते हैं कि ये फ़ंक्शन सही तरीके से काम करते हैं। यह बहुत अच्छा है कि जटिलता को कम करने का एक ऐसा तरीका है, लेकिन आपको हमेशा इस बात की जानकारी होनी चाहिए कि क्या हम इस बात को अच्छी तरह से समझते हैं कि इस या उस फ़ंक्शन का हम क्या उपयोग करेंगे। और इसके लिए - RTFM!