इकाई फ्रेमवर्क समूह किसी ऑब्जेक्ट या कॉम्प्लेक्स टाइप

Question

क्या किसी ऑब्जेक्ट पर समूह को निष्पादित करना संभव है?

from item in context.Items 
group item by item.MyObject 
select ... 

कहाँ Item.MyObject जैसे एक साधारण वस्तु है:

public class MyObject { 
    public int SomeValue { get; set; } 
    public string SomeName { get; set; } 
    public string SomeOtherProperty { get; set; } 
} 

जाहिर है मैं निम्नलिखित कर सकता है:

from item in context.Items 
group item by new { item.SomeValue, item.SomeName, item.SomeOtherProperty } 
select ... 

लेकिन जब संपत्तियों की एक बहुत कुछ के साथ वस्तुओं के द्वारा समूहीकरण, यह दृष्टिकोण कठिन और त्रुटि प्रवण है।

उपर्युक्त कोड के परिणामस्वरूप निम्नलिखित संदेश के साथ एक समर्थित नहीं है: "समूहबी विधि 'के लिए कॉल का मुख्य चयनकर्ता अंतर्निहित स्टोर प्रदाता में तुलनीय नहीं है"। समानता और GetHashcode ओवरराइडिंग का कोई प्रभाव नहीं पड़ता है। मैं असली समस्या का अनुमान लगा रहा हूं कि इकाई ढांचे को एसक्यूएल को व्यक्त करने का तरीका नहीं पता है ...?

Answer 1

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

जहां तक ​​मेरा ज्ञान फैलता है, "स्पष्ट रूप से मैं निम्नलिखित कर सकता हूं:" एकमात्र तरीका संभव है। आपको या तो प्रति उप-कॉलम आधार पर समूह को परिभाषित करना होगा, या कुछ प्रकार के प्रक्षेपण द्वारा डेटाबेस को पता चलेगा कि तुलना कैसे करें।

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

पहला विकल्प, काफी लंगड़ा वाला, केवल ईएफ को अनदेखा करना और डेटाबेस से सीधे बात करना और हाथों से पंक्तियों/कॉलम को पढ़ने/अनुवाद/अनपैक करना है। खैर, हम एसक्लक्लिएंट जानते हैं, हम ऐसा कर सकते हैं।

दूसरा विकल्प, बदसूरत, ईएफ में एक स्टब टेबल/व्यू में परिभाषित करना है, उदाहरण के लिए ग्राहक दृश्य, जिसमें केवल {नाम, पता, संपर्क फोन, जूता आकार} कॉलम होंगे, और संग्रहित प्रक्रिया परिणाम सेट को मानचित्रित करें इसके लिए यह अच्छी तरह से काम करेगा, लेकिन यदि आप दुर्घटनाग्रस्त 'डेटाबेस उत्पन्न करते हैं' ईएफ मॉडल बनाते हैं, तो आपको वह अतिरिक्त अप्रयुक्त तालिका भी मिल जाएगी ..

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

यह बहुत अच्छा है, लेकिन ठीक है, आप इस तरह के डेटा प्रकार को किसी प्रक्रिया से क्यों वापस करना चाहते थे? शायद, प्रक्रिया को संसाधित या उत्पन्न कुछ डेटा, और आप कुछ तालिका में उन्हें स्टोर करना चाहते हैं। आपने पूरी सामान्य इकाई को परिभाषित नहीं किया है, इसलिए यह बात सिर्फ 'डेटा पैक' है, इसलिए आप शायद उस डेटा को उस डेटा के साथ अन्य डेटा के साथ परिणाम मान लिखेंगे। और यही कारण है कि ईएफ आपको कॉम्प्लेक्स टाइप को किसी तालिका के कुछ कॉलम पर मैप करने की अनुमति देता है: यदि आपको उस प्रक्रिया से अस्थायी परिणाम ऑब्जेक्ट मिला है और अब आप इसे कहीं लिखना चाहते हैं, तो आपको इसे मैन्युअल रूप से कॉलम-बाय-कॉलम नहीं करना है , आप इसे ग्राहक के कॉलम "नाम, पता, संपर्क फोन, जूता आकार" के लिए मानचित्र बनाते हैं।

सबसे महत्वपूर्ण बात यह है कि डेटाबेस सर्वर कभी भी इस तरह के कॉम्प्लेक्स टाइप अस्तित्व में नहीं जानता है। जैसा कि मैंने कहा, इसकी कोई पहचान नहीं थी। जब आप की तरह

aset.Where(item => item.complexProperty == complexValue) 

तो एक LINQ क्वेरी करने की कोशिश, complexValue, एक CLR उद्देश्य यह है कि किसी भी मेज पर मैप नहीं है कोई पहचान नहीं है, इस प्रकार नहीं पी है, इस प्रकार एफई पूरी तरह से नहीं विचार कैसे जांच करने के लिए है "बायां हाथ ऑब्जेक्ट" "दायां हाथ ऑब्जेक्ट" जैसा ही है। वस्तुओं को कुछ पहचान परिभाषित किया गया था, यह सर्वर पक्ष पर पीके की जांच कर सकता था, या क्लाइंट पक्ष पर ऑब्जेक्ट-रेफरेंस तुलना कर सकता था, लेकिन यहां - यह बस विफल हो जाता है।

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