अधिकांश डेवलपर्स के लिए, अभिव्यक्ति पेड़ का उपयोग LINQ में लंबोदर अभिव्यक्तियों तक सीमित है। अक्सर हम किसी भी महत्व को नहीं जोड़ते हैं कि तकनीक "हुड के तहत" कैसे काम करती है।

इस लेख में मैं आपको अभिव्यक्ति के पेड़ के साथ काम करने के लिए उन्नत तकनीक दिखाऊंगा: LINQ में कोड के दोहराव को खत्म करना, कोड जनरेशन, मेटाप्रोग्रामिंग, ट्रांसप्लिमेंटेशन, टेस्ट ऑटोमेशन।

आप सीखेंगे कि अभिव्यक्ति के पेड़ का सीधे उपयोग कैसे करें, तकनीक ने क्या नुकसान किए हैं, और उनके आसपास कैसे पहुंचें।



DotNext 2018 Piter के साथ मेरी रिपोर्ट के कट - वीडियो और टेक्स्ट ट्रांसक्रिप्ट के तहत।


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

मैं विशेष रूप से अभिव्यक्ति के पेड़ों की आंतरिक संरचना का अध्ययन नहीं करना चाहता था, ऐसा लगता था कि यह LINQ के लिए काम करने के लिए .NET टीम के लिए कुछ प्रकार की आंतरिक तकनीक थी, और एप्लिकेशन प्रोग्रामर को इसके एपीआई को जानने की आवश्यकता नहीं थी। यह पता चला कि कुछ लागू समस्याएं थीं जिन्हें हल करने की आवश्यकता थी। ताकि मुझे समाधान पसंद आया, मुझे आंत में चढ़ना पड़ा।

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



कल्पना कीजिए कि हम सभी एक ऑनलाइन स्टोर लिख रहे हैं। इसमें व्यवस्थापक पैनल में उत्पाद और एक चेकमार्क "फॉर सेल" है। हम केवल उन्हीं उत्पादों को प्रदर्शित करेंगे जिनके पास सार्वजनिक भाग पर यह चेकमार्क अंकित है।



हम कुछ DbContext या NHibernate लेते हैं, हम लिखते हैं कि कहां (), हम IsForSale का उत्पादन करते हैं।

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



हम आसानी से ऐसी संपत्ति जोड़ लेते हैं। अब हमारे व्यावसायिक नियम समाप्त हो गए हैं, हम उनका पुन: उपयोग कर सकते हैं।



LINQ को एडिट करने की कोशिश करते हैं। क्या यहाँ सब ठीक है?
नहीं, यह काम नहीं करेगा, क्योंकि IsAvailable डेटाबेस में किसी भी तरह से मैप नहीं करता है, यह हमारा कोड है, और क्वेरी प्रदाता यह नहीं जानता कि इसे पार्स कैसे किया जाए।



हम उसे बता सकते हैं कि हमारी संपत्ति में ऐसी कहानी है। लेकिन अब इस लैंबडा को लाइनक अभिव्यक्ति और संपत्ति दोनों में दोहराया गया है।

Where(x => x.IsForSale && x.InStock > 0) IsAvailable => IsForSale && InStock > 0; 

इसलिए, अगली बार जब यह लंबा बदलता है, तो हमें प्रोजेक्ट पर Ctrl + Shift + F करना होगा। स्वाभाविक रूप से, हम सभी को नहीं मिलेगा - बग और समय। मैं इससे बचना चाहता हूं।



हम इस तरफ से जा सकते हैं और एक और ToList () को कहां () के सामने रख सकते हैं। यह एक बुरा निर्णय है, क्योंकि अगर डेटाबेस में एक लाख का सामान है, तो हर कोई रैम और फ़िल्टर करने के लिए उठता है।



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



एक प्रतिनिधि को अभिव्यक्ति से स्थानांतरित करने के लिए, आपको बस संकलन () विधि को कॉल करने की आवश्यकता है। यह एपीआई .NET प्रदान करता है: अभिव्यक्ति है - संकलित, एक प्रतिनिधि प्राप्त किया।

लेकिन वापस कैसे जाएं? वहाँ एक प्रतिनिधि से अभिव्यक्ति पेड़ के लिए आगे बढ़ने में कुछ भी नहीं है? यदि आप उदाहरण के लिए, LISP से परिचित हैं, तो एक उद्धरण तंत्र है जो कोड को डेटा संरचना के रूप में व्याख्या करने की अनुमति देता है, लेकिन .NET में यह नहीं है।

एक्सप्रेस या प्रतिनिधियों?

यह मानते हुए कि हमारे पास दो प्रकार के लंबोदे हैं, हम यह दार्शनिक कर सकते हैं कि प्राथमिक क्या है: अभिव्यक्ति पेड़ या प्रतिनिधि।

 // so slo-oooooo-ow var delegateLambda = expressionLambda.Compile(); 

पहली नज़र में, जवाब स्पष्ट है: चूंकि एक अद्भुत संकलन () विधि है, अभिव्यक्ति का पेड़ प्राथमिक है। और हमें अभिव्यक्ति को संकलित करके प्रतिनिधि को प्राप्त करना चाहिए। लेकिन संकलन एक धीमी प्रक्रिया है, और अगर हम हर जगह ऐसा करना शुरू करते हैं, तो हमें प्रदर्शन में गिरावट आती है। इसके अलावा, हम इसे यादृच्छिक स्थानों पर प्राप्त करेंगे, जहां अभिव्यक्ति को एक प्रतिनिधि में संकलित करना था, एक प्रदर्शन में कमी होगी। आप इन स्थानों को पा सकते हैं, लेकिन वे सर्वर के प्रतिक्रिया समय को प्रभावित करेंगे, और बेतरतीब ढंग से।



इसलिए, उन्हें किसी तरह कैश करने की आवश्यकता है। यदि आपने समवर्ती डेटा संरचनाओं के बारे में बात सुनी है, तो आप समवर्ती (या इसके बारे में बस जानते हैं) के बारे में जानते हैं। मैं कैशिंग विधियों (ताले के साथ, ताले नहीं) के बारे में विवरण छोड़ दूंगा। बस यह है कि समवर्ती छाया में एक सरल GetOrAdd () विधि है, और सबसे सरल कार्यान्वयन इसे समवर्ती छाया में पॉप करना और इसे कैश करना है। पहली बार हम संकलन प्राप्त करते हैं, लेकिन फिर सब कुछ तेजी से होगा, क्योंकि प्रतिनिधि पहले ही संकलित किया जा चुका है।



फिर आप इस तरह के एक विस्तार विधि का उपयोग कर सकते हैं, आप हमारे कोड का उपयोग कर सकते हैं और इसे IsAvailable () के साथ रिफैक्ट कर सकते हैं, अभिव्यक्ति का वर्णन कर सकते हैं, IsAvailable () गुणों का संकलन कर सकते हैं और इसे वर्तमान ऑब्जेक्ट के सापेक्ष कॉल कर सकते हैं।

कम से कम दो पैकेज हैं जो इसे लागू करते हैं: Microsoft.Linq.Translations और Signum Framework (एक वाणिज्यिक कंपनी द्वारा लिखित खुला स्रोत ढांचा)। दोनों वहाँ और प्रतिनिधियों के संकलन के साथ एक ही कहानी के बारे में हैं। थोड़ा अलग एपीआई, लेकिन जैसा कि मैंने पिछली स्लाइड में दिखाया था।

हालांकि, यह एकमात्र तरीका नहीं है, और आप प्रतिनिधियों से अभिव्यक्तियों तक जा सकते हैं। लंबे समय से डेलीगेट डेकोम्पाइलर के बारे में हब्रे पर एक लेख आया है, जहां लेखक का दावा है कि सभी संकलन खराब है, क्योंकि लंबे समय तक।

सामान्य तौर पर, प्रतिनिधि अभिव्यक्ति से पहले थे, और आप प्रतिनिधियों से उन पर आगे बढ़ सकते हैं। ऐसा करने के लिए, लेखक methodBody.GetILAsByteArray () का उपयोग करता है; प्रतिबिंब से, जो वास्तव में बाइट के एक सरणी के रूप में विधि के पूरे आईएल कोड को वापस करता है। यदि आप इसे प्रतिबिंब में आगे रखते हैं, तो आप इस मामले का एक वस्तु प्रतिनिधित्व प्राप्त कर सकते हैं, एक लूप के माध्यम से जा सकते हैं और एक अभिव्यक्ति ट्री बना सकते हैं। इस प्रकार, एक रिवर्स संक्रमण भी संभव है, लेकिन इसे हाथ से करना होगा।



सभी संपत्तियों के माध्यम से नहीं चलाने के लिए, लेखक यह इंगित करने के लिए कि इस संपत्ति को इनलेट करने की आवश्यकता है, कम्प्यूटेड विशेषता को लटकाने का सुझाव देता है। अनुरोध से पहले, हम IsAvailable () में चढ़ते हैं, इसके IL-code को बाहर निकालते हैं, इसे अभिव्यक्ति ट्री में परिवर्तित करते हैं और IsAvailable () कॉल को इस गेटर में लिखे गए से बदल देते हैं। यह ऐसी मैनुअल इनलाइनिंग का पता लगाता है।



यह काम करने के लिए, ToList () के लिए सब कुछ पारित करने से पहले, हम विशेष विधि को Decompile () कहते हैं। यह मूल क्वेरी और इनलाइनिंग के लिए एक डेकोरेटर प्रदान करता है। उसके बाद ही हम क्वेरी प्रदाता को सब कुछ पास करते हैं, और हमारे साथ सब कुछ ठीक है।



इस दृष्टिकोण के साथ एकमात्र समस्या यह है कि डेलिगेट डेकोम्पेलर 0.23.0 आगे नहीं बढ़ने वाला है, कोई कोर सपोर्ट नहीं है, और लेखक खुद कहते हैं कि यह गहरे अल्फ़ा है, बहुत सारे अधूरे हैं, इसलिए आप इसे उत्पादन में शामिल नहीं कर सकते। यद्यपि हम इस विषय पर लौटेंगे।

बूलियन ऑपरेशन

यह पता चला है कि हमने विशिष्ट परिस्थितियों के दोहराव की समस्या को हल कर दिया है।



लेकिन अक्सर बूलियन तर्क का उपयोग करके स्थितियों को संयोजित करने की आवश्यकता होती है। हमारे पास IsForSale (), InStock ()> 0, और उनके बीच की स्थिति "AND" है। यदि कोई अन्य शर्त है, या "ओआर" स्थिति की आवश्यकता है।



"और," के मामले में, आप क्वेरी प्रदाता पर सभी काम को धोखा दे सकते हैं और डंप कर सकते हैं, अर्थात, एक पंक्ति में बहुत सारे कहाँ () लिखें, वह जानता है कि यह कैसे करना है।



यदि "OR" आवश्यक है, तो यह काम नहीं करेगा, क्योंकि जहां LINO () LINQ में नहीं है, और ऑपरेटर | भाव के साथ अधिभार नहीं है।

विनिर्देश

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



एक विनिर्देश ऐसा शब्द है, जो जावा से एक पुराना पैटर्न है। और जावा में, विशेष रूप से पुराने एक में, कोई LINQ नहीं था, इसलिए इसे केवल isSatisfiedBy () विधि के रूप में वहां लागू किया गया था, जो कि केवल प्रतिनिधियों के लिए है, लेकिन अभिव्यक्ति के बारे में कोई बात नहीं थी। इंटरनेट पर एक कार्यान्वयन है जिसे LinqSpecs कहा जाता है, स्लाइड पर आप इसे देखेंगे। मैंने इसे अपने लिए थोड़ा सा दर्ज किया, लेकिन यह विचार पुस्तकालय का है।

यहां, सभी बूलियन ऑपरेटरों को ओवरलोड किया जाता है, सच्चे और झूठे ऑपरेटरों को ओवरलोड किया जाता है ताकि दो ऑपरेटर "&" और "" "काम करें, उनके बिना केवल एक एम्परसेंड काम करेगा।



अगला, हम निहित बयान जोड़ते हैं जो संकलक को यह मान लेते हैं कि विनिर्देश अभिव्यक्ति और प्रतिनिधि दोनों हैं। किसी भी स्थान पर जहां एक्सप्रेशन <> या फंक <> फंक्शन में आना चाहिए, आप स्पेसिफिकेशन पास कर सकते हैं। चूंकि अंतर्निहित ऑपरेटर ओवरलोडेड है, इसलिए कंपाइलर एक्सप्रेशन या IsSatisfiedBy गुणों को पार्स और स्थानापन्न करेगा।



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

 public static readonly Spec<Product> IsForSaleSpec = new Spec<Product>(x => x.IsForSale); public static readonly Spec<Product> IsInStockSpec = new Spec<Product>(x => x.InStock > 0); 

प्रत्येक व्यापार नियम केवल एक बार लिखा जाता है, यह कहीं भी खो नहीं जाएगा, इसे डुप्लिकेट नहीं किया जाएगा, उन्हें जोड़ा जा सकता है। परियोजना में आने वाले लोग देख सकते हैं कि आपके पास क्या है, क्या स्थितियां हैं, विषय मॉडल को समझें।



एक छोटी सी समस्या है: अभिव्यक्ति में और (), या (और) और () विधियां नहीं हैं। ये विस्तार विधियां हैं, इन्हें स्वतंत्र रूप से लागू किया जाना चाहिए।



कार्यान्वयन का पहला प्रयास यह था। अभिव्यक्ति के पेड़ के बारे में, इंटरनेट पर काफी प्रलेखन है, और यह सब विस्तृत नहीं है। इसलिए, मैंने एक्सप्रेशन लेने की कोशिश की, Ctrl + Space दबाया, OrElse () देखा, इसके बारे में पढ़ा। संकलित करने और लैम्ब्डा प्राप्त करने के लिए दो अभिव्यक्ति उत्तीर्ण की। यह काम नहीं करेगा।



तथ्य यह है कि इस अभिव्यक्ति में दो भाग होते हैं: पैरामीटर और बॉडी। दूसरे में एक पैरामीटर और एक बॉडी भी होती है। OrElse () में, आपको अभिव्यक्ति के निकायों को पास करने की आवश्यकता है, अर्थात, "एंड" और "ओआर" के साथ लैम्ब्डा की तुलना करना बेकार है, यह काम नहीं करेगा। हम ठीक करते हैं, लेकिन यह फिर से काम नहीं करेगा।

लेकिन अगर पिछली बार एक NotSupportedException थी कि लैम्ब्डा का समर्थन नहीं किया गया था, तो अब पैरामीटर 1, पैरामीटर 2, "कुछ गलत है, मैंने काम नहीं किया है" के बारे में एक अजीब कहानी है।

संक्षेप में सी # 7.0

तब मुझे लगा कि वैज्ञानिक प्रहार विधि काम नहीं करेगी, मुझे इसका पता लगाने की आवश्यकता है। उन्होंने गूगल करना शुरू किया और अल्ताहारी की पुस्तक " नटशेल में C # 7.0 " को पाया।



जोसेफ अलबहारी, जो लोकप्रिय LINQKit लाइब्रेरी और LINQPad के डेवलपर भी हैं, बस इस समस्या का वर्णन करते हैं। आप एक्सप्रेशन को बस ले और संयोजित नहीं कर सकते हैं, और यदि आप मैजिक एक्सप्रेशन लेते हैं। Invoke (), यह काम करेगा।

प्रश्न: अभिव्यक्ति क्या है। इंवोक ()? फिर से Google पर जाएं। यह एक InvocationExpression बनाता है जो तर्क सूची में एक प्रतिनिधि या लैम्ब्डा अभिव्यक्ति को लागू करता है।



अगर मैं इस कोड को आपको अभी पढ़ता हूं कि हम एक्सप्रेशन लेते हैं। इंवोक (), हम मापदंडों को पास करते हैं, तो वही बात अंग्रेजी में लिखी जाती है। यह साफ नहीं हो रहा है। कुछ जादू अभिव्यक्ति है। इंवोक () जो किसी कारण से इस समस्या को मापदंडों के साथ हल करता है। हमें विश्वास करना चाहिए, यह समझना आवश्यक नहीं है।



उसी समय, यदि आप ईएफएस को इस तरह के संयुक्त अभिव्यक्ति को खिलाने की कोशिश करते हैं, तो यह फिर से गिर जाएगा और कहेंगे कि अभिव्यक्ति। इंवोक () समर्थित नहीं है। वैसे, ईएफ कोर ने समर्थन करना शुरू किया, लेकिन ईएफ 6 पकड़ में नहीं आता है। लेकिन अलबाहरी सिर्फ AsExpandable () लिखने की पेशकश करती है, और यह सब काम करता है।



और आप अभिव्यक्ति उपश्रेणियों में स्थानापन्न कर सकते हैं जहां हमें एक प्रतिनिधि की आवश्यकता है। उन्हें मैच करने के लिए, हम कम्पाइल () लिखते हैं, लेकिन साथ ही, अगर हम AsExpandable () लिखते हैं, जैसा कि अल्बाहारी सुझाव देते हैं, यह कंपाइल () वास्तव में नहीं होगा, लेकिन सब कुछ किसी भी तरह से जादुई रूप से सही ढंग से होगा।



मुझे एक शब्द पर विश्वास नहीं हुआ और स्रोत में चढ़ गया। AsExpandable () विधि क्या है? इसमें क्वेरी और QueryOptimizer है। हम कोष्ठक से दूसरे को छोड़ देंगे, क्योंकि यह दिलचस्प नहीं है, लेकिन बस झलकें अभिव्यक्ति: यदि 3 + 5 है, तो यह 8 डाल देगा।



यह दिलचस्प है कि विस्तार () विधि को बाद में कहा जाता है, इसके बाद क्वेरीओप्टिमाइज़र, और फिर सब कुछ क्वेरी प्रदाता को दिया जाता है किसी भी तरह से विस्तार () विधि के बाद फिर से किया जाता है।



हम इसे खोलते हैं, यह आगंतुक है, अंदर हम गैर-मूल संकलन () को देखते हैं, जो कुछ और संकलन करता है। मैं आपको यह नहीं बताऊंगा कि वास्तव में क्या है, भले ही इसका एक निश्चित अर्थ है, लेकिन हम एक संकलन को हटा देते हैं और इसे दूसरे के साथ बदल देते हैं। शानदार, लेकिन यह 80 के स्तर की मार्केटिंग में दम तोड़ देता है क्योंकि प्रदर्शन का प्रभाव कहीं नहीं जा रहा है।

विकल्प की तलाश में

मैंने सोचा कि यह काम नहीं करेगा और दूसरे समाधान की तलाश शुरू कर दी। और मिल गया। ऐसे पीट मोंटगोमरी हैं जो इस समस्या के बारे में भी लिखते हैं और दावा करते हैं कि अलबहारी फेक है।

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

ऐसा करने के लिए, आपको भावों के मापदंडों को देखकर एक शब्दकोश संकलित करने की आवश्यकता है, यदि लंबोदर एक पैरामीटर से नहीं है। हम एक शब्दकोश की रचना करते हैं, और हम दूसरे के सभी मापदंडों को पहले के मापदंडों से फिर से बाँधते हैं, ताकि प्रारंभिक पैरामीटर अभिव्यक्ति में प्रवेश करें, पूरे शरीर के माध्यम से ड्राइव करें जिसे हमने एक साथ चिपका दिया था।

इस तरह की एक सरल विधि आपको अभिव्यक्ति के साथ सभी घात से छुटकारा पाने की अनुमति देती है। इंवोक ()। इसके अलावा, पीट मोंटगोमरी के कार्यान्वयन में, यह और भी ठंडा बनाया गया है। इसमें एक Compose () विधि है जो आपको किसी भी अभिव्यक्ति को संयोजित करने की अनुमति देती है।



हम अभिव्यक्ति लेते हैं और AndAlso के माध्यम से हम कनेक्ट करते हैं, एक्सपेंडेबल () के बिना काम करते हैं। यह यह कार्यान्वयन है जो बूलियन संचालन में उपयोग किया जाता है।

विनिर्देशों और इकाइयों

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



यदि, सामानों के अलावा, अभी भी एक व्यवसाय नियम के साथ श्रेणियां हैं जो उनके लिए एक विनिर्देश के रूप में घोषित की गई हैं, तो एक निश्चित रेटिंग है जो 50 से अधिक होनी चाहिए, जैसा कि मार्केटर्स ने कहा और हम इसे उसी तरह से उपयोग करना चाहते हैं, तो यह अच्छा है।



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



फिर, हमें किसी तरह समस्या को हल करने की आवश्यकता है। पहला विकल्प: SelectMany () का चयन Select () से करें। मैं यहां दो चीजों की तरह नहीं हूं। सबसे पहले, मुझे पता नहीं है कि सभी लोकप्रिय क्वेरी प्रदाताओं में SelectMany () समर्थन कैसे लागू किया जाता है। दूसरे, यदि कोई क्वेरी प्रदाता लिखता है, तो वह जो पहली चीज करेगा, वह है थ्रो अपवाद और सिलेक्टमनी () नहीं है। और तीसरा बिंदु: लोग सोचते हैं कि SelectMany () या तो कार्यक्षमता है, या जुड़ता है, आमतौर पर एक SELECT क्वेरी से जुड़ा नहीं होता है।

रचना

मैं Select () का उपयोग करना चाहूंगा, SelectMany () का नहीं।



लगभग उसी समय, मैंने श्रेणी सिद्धांत के बारे में, कार्यात्मक रचना के बारे में पढ़ा और सोचा कि यदि नीचे दिए गए बूल में उत्पाद से विनिर्देश हैं, तो कुछ फ़ंक्शन हैं जो उत्पाद से श्रेणी में जा सकते हैं, श्रेणी के संबंध में एक विनिर्देश है, फिर पहले प्रतिस्थापन दूसरे के तर्क के रूप में कार्य करें, हमें वह मिलता है जो हमें चाहिए, उत्पाद के बारे में एक विनिर्देश। बिल्कुल कार्यात्मक रचना के समान है, लेकिन अभिव्यक्ति के पेड़ के लिए।



फिर इस तरह की कहां () विधि लिखना संभव होगा कि उत्पादों से श्रेणियों में स्थानांतरित करना और इस संबंधित इकाई के लिए विनिर्देश लागू करना आवश्यक है। मेरे व्यक्तिपरक स्वाद के लिए इस तरह के वाक्यविन्यास बहुत समझ में आता है।

 public static IQueryable<T> Where<T, TParam>(this IQueryable<T> queryable, Expression<Func<T, TParam>> prop, Expression<Func<TParam, bool>> where) { return queryable.Where(prop.Compose(where)); } 

कम्पोज़ () विधि के साथ, यह भी आसानी से किया जा सकता है। हम उत्पादों से इनपुट एक्सप्रेशन लेते हैं और इसे उत्पाद के विनिर्देशों के साथ जोड़ते हैं और यही है।



अब आप ऐसा कहां () लिख सकते हैं। यदि आपके पास किसी भी लम्बाई की मशीन है तो यह काम करेगा। श्रेणी में एक SuperCategory और किसी भी संख्या में आगे के गुण हैं जिन्हें प्रतिस्थापित किया जा सकता है।

"चूंकि हमारे पास कार्यात्मक संरचना के लिए एक उपकरण है, और चूंकि हम इसे संकलित कर सकते हैं, और चूंकि हम इसे गतिशील रूप से इकट्ठा कर सकते हैं, इसका मतलब है कि मेटा-प्रोग्रामिंग की एक गंध है!" मैंने सोचा।

प्रक्षेपण

हम मेटा-प्रोग्रामिंग कहां लागू कर सकते हैं ताकि हमें कम कोड लिखना पड़े।



पहला विकल्प प्रक्षेपण है। एक संपूर्ण इकाई को बाहर निकालना अक्सर बहुत महंगा होता है। अक्सर हम इसे सामने से गुजारते हैं, JSON को क्रमबद्ध करते हैं। लेकिन इसमें एग्रीगेट के साथ पूरे सार की जरूरत नहीं है। आप ऐसा चयन () मैन्युअल रूप से लिखकर यथासंभव LINQ के साथ कर सकते हैं। मुश्किल नहीं है, लेकिन उबाऊ है।



इसके बजाय, मेरा सुझाव है कि सभी लोग ProjectToType () का उपयोग करें। कम से कम दो पुस्तकालय हैं जो ऐसा कर सकते हैं: ऑटोमैपर और मैपस्टर। किसी कारण से, बहुत से लोग जानते हैं कि AutoMapper मेमोरी में मैपिंग कर सकता है, लेकिन हर कोई नहीं जानता है कि इसमें क्वेरी एक्सटेंशन है, इसमें एक्सप्रेशन भी है, और यह SQL अभिव्यक्ति का निर्माण कर सकता है। यदि आप अभी भी मैनुअल क्वेरी लिखते हैं और आप LINQ का उपयोग करते हैं, क्योंकि आपके पास सुपर-गंभीर प्रदर्शन की कमी नहीं है, तो इसे अपने हाथों से करने का कोई मतलब नहीं है, यह मशीन का काम है, न कि व्यक्ति का।

छानने

यदि हम अनुमानों के साथ ऐसा कर सकते हैं, तो इसे फ़िल्टर करने के लिए क्यों न करें।



यहाँ भी कोड है। एक फिल्टर आता है। बहुत सारे व्यावसायिक अनुप्रयोग इस तरह दिखते हैं: एक फ़िल्टर आया, कहाँ जोड़ें (), दूसरा फ़िल्टर आया, कहाँ जोड़ें ()। कितने फिल्टर हैं, बहुत सारे हैं और दोहराते हैं। कुछ भी जटिल नहीं है, लेकिन बहुत सारे कॉपी-पेस्ट।



यदि हम, AutoMapper के रूप में, यह करते हैं, तो AutoFilter, प्रोजेक्ट और फ़िल्टर लिखें ताकि वह स्वयं सब कुछ करे, यह अच्छा होगा - कम कोड।



यह कुछ भी जटिल नहीं है। एक्सप्रेशन ले लीजिए। तेज, डीटीओ के माध्यम से और संक्षेप में चलें। हमें सामान्य गुण मिलते हैं जिन्हें पहचान कहा जाता है। यदि उन्हें समान कहा जाता है, तो यह एक फिल्टर जैसा दिखता है।

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



फिर लैम्ब्डा इकट्ठा करें और प्रत्येक संपत्ति के लिए जाएं: यदि उनमें से बहुत से हैं, तो "एंड" या "ओआर" के माध्यम से इकट्ठा करें, यह इस बात पर निर्भर करता है कि फ़िल्टर आपके लिए कैसे काम करता है।



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

प्रश्न उठता है: कहां रखा जाना चाहिए () - इकाई स्तर पर, जैसा कि विनिर्देशों की घोषणा की गई थी या प्रक्षेपण के बाद, और वहां और वहां यह काम करेगा।



यह दोनों सच है, और इसलिए, क्योंकि विनिर्देश हैं, परिभाषा के अनुसार, व्यापार नियम, और हमें उन्हें संजोना और संजोना चाहिए और उनके साथ कोई गलती नहीं करनी चाहिए। यह एक आयामी परत है। और फिल्टर UI के बारे में अधिक हैं, जिसका अर्थ है कि वे डीटीओ द्वारा फ़िल्टर करते हैं। इसलिए, आप दो को कहां रख सकते हैं ()। इस बात की अधिक संभावना है कि क्वेरी प्रदाता इस कुएं को कितनी अच्छी तरह से संभालेंगे, लेकिन मेरा मानना ​​है कि ORM समाधान वैसे भी खराब SQL लिखते हैं, और यह बहुत बुरा नहीं है। यदि यह आपके लिए बहुत महत्वपूर्ण है, तो यह कहानी आपके बारे में बिल्कुल भी नहीं है।



जैसा कि वे कहते हैं, सौ बार सुनने की तुलना में एक बार देखना बेहतर है।
अब स्टोर में तीन उत्पाद हैं: स्निकर्स, सुबारू इम्पेर्ज़ा और मार्स। अजीब दुकान। आइए Snickers को खोजने की कोशिश करते हैं। वहाँ है आइए देखें कि सौ रूबल क्या है। इसके अलावा स्नीकर्स। और 500 के लिए? ज़ूम इन करें, कुछ नहीं है। और 100500 सुबारू इम्प्रेज़ा के लिए। महान, वही छँटाई के लिए जाता है।

वर्णानुक्रम में और मूल्य के अनुसार क्रमबद्ध करें। वहां का कोड उतना ही लिखा गया है जितना वह था। ये फिल्टर किसी भी वर्ग के लिए काम करते हैं, जो भी हो। यदि आप नाम से खोजने की कोशिश करते हैं, तो सुबारू भी मौजूद है। और मेरी प्रस्तुति में बराबर () था। ऐसा कैसे? तथ्य यह है कि यहां और प्रस्तुति में कोड थोड़ा अलग हैं। मैंने इक्वाल्स () के बारे में लाइन पर टिप्पणी की और कुछ विशेष स्ट्रीट मैजिक को जोड़ा। अगर हमारे पास String टाइप है, तो हमें Equals () नहीं, बल्कि StartWith () कहते हैं, जो मुझे भी मिला है। इसलिए, पंक्तियों के लिए एक अलग फ़िल्टर बनाया गया है।



इसका मतलब यह है कि यहां आप Ctrl + Shift + R दबा सकते हैं, विधि का चयन कर सकते हैं और यदि नहीं, लेकिन स्विच कर सकते हैं, या आप "रणनीति" पैटर्न भी लागू कर सकते हैं और फिर पागल हो सकते हैं। आप फिल्टर के संचालन के बारे में किसी भी इच्छाओं को महसूस कर सकते हैं। यह सब उन प्रकारों पर निर्भर करता है जिनके साथ आप काम करते हैं। सबसे महत्वपूर्ण बात, फ़िल्टर वही काम करेंगे।

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

मान्यता

फ़िल्टरिंग और प्रोजेक्शन के अलावा, आप सत्यापन कर सकते हैं। जेएस पुस्तकालय TComb.validation इस विचार के साथ आया था। टीसीबॉम टाइप संयोजकों का एक संक्षिप्त नाम है और यह एक प्रकार की प्रणाली पर आधारित है। शोधन, सुधार।

 // null and undefined validate('a', t.Nil).isValid(); // => false validate(null, t.Nil).isValid(); // => true validate(undefined, t.Nil).isValid(); // => true // strings validate(1, t.String).isValid(); // => false validate('a', t.String).isValid(); // => true // numbers validate('a', t.Number).isValid(); // => false validate(1, t.Number).isValid(); // => true 

सबसे पहले, सभी जेएस प्रकारों के लिए आदिम घोषित किए जाते हैं, और एक अतिरिक्त शून्य प्रकार या तो अपरिभाषित या शून्य।

 // a predicate is a function with signature: (x) -> boolean var predicate = function (x) { return x >= 0; }; // a positive number var Positive = t.refinement(t.Number, predicate); validate(-1, Positive).isValid(); // => false validate(1, Positive).isValid(); // => true 

फिर मस्ती शुरू होती है। प्रत्येक प्रकार को एक विधेय के साथ बढ़ाया जा सकता है। यदि हम संख्याओं को शून्य से अधिक चाहते हैं, तो हम विधेय x> = 0 को घोषित करते हैं और सकारात्मक प्रकार के संबंध में सत्यापन करते हैं। इसलिए बिल्डिंग ब्लॉक्स से आप अपनी कोई भी मान्यता एकत्र कर सकते हैं। हमने ध्यान दिया, शायद, लैम्बडा एक्सप्रेशन भी हैं।



कॉल स्वीकार किया जाता है। हम एक ही परिशोधन लेते हैं, इसे C # में लिखते हैं, IsValid () विधि लिखते हैं, और साथ ही अभिव्यक्ति को संकलित और निष्पादित करते हैं। अब हमारे पास सत्यापन करने का अवसर है।

 public class RefinementAttribute: ValidationAttribute { public IValidator<object> Refinement { get; } public RefinementAttribute(Type refinmentType) { Refinement = (IValidator<object>) Activator.CreateInstance(refinmentType); } public override bool IsValid(object value) => Refinement.Validate(value).IsValid(); } 

हम ASP.NET MVC में मानक DataAnnotations सिस्टम के साथ एकीकृत करते हैं ताकि यह सभी बॉक्स से बाहर काम करे। हम RefinementAttribute घोषित करते हैं (), कंस्ट्रक्टर के पास टाइप करें। तथ्य यह है कि RefinementAttribute जेनेरिक है, इसलिए आपको इस प्रकार का उपयोग करना होगा क्योंकि आप दुर्भाग्यवश .NET में जेनेरिक विशेषता की घोषणा नहीं कर सकते।



तो उपयोगकर्ता वर्ग को पुनर्वित्त के साथ चिह्नित करें। AdultRefinement, वह आयु 18 से अधिक



है। पूरी तरह से अच्छा होने के लिए, ग्राहक और सर्वर पर सत्यापन समान करें। NoJS समर्थकों ने JS पर बैकिंग और फ्रंट लिखने का सुझाव दिया। ठीक है, मैं C # में वापस और आगे लिखूंगा, यह ठीक है और मैं इसे केवल JS में स्थानांतरित करता हूं। जावास्क्रिप्ट अपने JSX, ES6 में लिख सकते हैं और इसे जावास्क्रिप्ट में अनुवाद कर सकते हैं। हम क्यों नहीं कर सकते? हम आगंतुक लिखते हैं, जिसके माध्यम से ऑपरेटरों की आवश्यकता होती है और जावास्क्रिप्ट लिखते हैं।



एक अलग लगातार सत्यापन का मामला नियमित अभिव्यक्ति है, उन्हें भी अलग करना होगा। यदि आपके पास regexp है, तो StringBuilder लें, regexp का निर्माण करें। यहां मैंने दो विस्मयबोधक बिंदुओं का उपयोग किया है, क्योंकि जेएस एक गतिशील रूप से टाइप की गई भाषा है, इस अभिव्यक्ति को हमेशा बूल के लिए डाला जाएगा, ताकि प्रकार के साथ सब कुछ ठीक हो। आइए देखें कि यह कैसा दिखता है।

 { predicate: “x=> (x >= 18)”, errorMessage: “For adults only» } 

यहाँ हमारी रिफाइनिंग है, जो बैकएंड से आती है, एक लाइन प्रेडिकेट करती है, जैसे कि JS में कोई लैम्बडा और एररमैसेज नहीं है "केवल वयस्कों के लिए"। आइए फॉर्म भरने की कोशिश करें। पास नहीं होता। हम देखते हैं कि यह कैसे बनाया जाता है।

यह प्रतिक्रिया है, हम बैकएंड से UserRefinment () मेथड एक्सप्रेशन एंड एरर मेसेजेज से रिक्वेस्ट करते हैं, संख्या के सापेक्ष रिफाइनमेंट का निर्माण करते हैं, लैम्डा प्राप्त करने के लिए eval का उपयोग करते हैं। यदि मैं इसे फिर से बनाता हूं और प्रकार के प्रतिबंध हटाता हूं, तो इसे सामान्य संख्या से बदल दें, सत्यापन जेएस पर गिर जाएगा। यूनिट दर्ज करें, भेजें। मुझे नहीं पता कि यह दिखाई दे रहा है या नहीं, यहाँ झूठा दिखाया गया है।



कोड अलर्ट है। जब हम onSubmit भेजते हैं, तो अलर्ट करें कि बैकएंड से क्या आया। और बैकएंड इतना सरल कोड है।



हम केवल Ok (ModelState.IsValid) लौटाते हैं, उपयोगकर्ता वर्ग जो हमें जावास्क्रिप्ट में फॉर्म से मिलता है। यहाँ यह शोधन विशेषता है।

 using … namespace DemoApp.Core { public class User: HasNameBase { [Refinement(typeof(AdultRefinement))] public int Age { get; set; } } } 

यही है, सत्यापन बैकएंड पर भी काम करता है, जिसे इस लंबोदर में घोषित किया गया है। और हम इसे जावास्क्रिप्ट में अनुवाद करते हैं। यह पता चला है, हम C # में लैम्ब्डा एक्सप्रेशन लिखते हैं, और कोड को वहां और वहां दोनों जगह निष्पादित किया जाता है। हमारा जवाब NoJS है, हम भी ऐसा कर सकते हैं।

परीक्षण

आमतौर पर यह टाइमलाइड्स हैं जो कोड में त्रुटियों की संख्या के बारे में अधिक चिंतित हैं। जो यूनिट परीक्षण लिखते हैं वे Moq लाइब्रेरी को जानते हैं। क्या आप नकली लिखना चाहते हैं या कुछ वर्ग घोषित करना चाहते हैं - वहाँ moq है, यह धाराप्रवाह वाक्य रचना है। आप पेंट कर सकते हैं कि आप उसे कैसे व्यवहार करना चाहते हैं और परीक्षण के लिए उसके आवेदन को पर्ची करें।

Moq में ये लंबोदर एक्सप्रेशन भी हैं, डेलिगेट्स नहीं। वह अभिव्यक्ति के पेड़ों से चलता है, अपने तर्क को लागू करता है, और फिर कैसल में काम करता है। और वह रनटाइम में आवश्यक कक्षाएं बनाता है। लेकिन हम ऐसा भी कर सकते हैं।



मेरे एक दोस्त ने हाल ही में पूछा कि क्या हमारे कोर में WCF जैसा कुछ था। मैंने जवाब दिया कि एक वेबएपीआई है। वह WebAPI में चाहता था, जैसा कि एक प्रॉक्सी बनाने के लिए WSDL पर WCF में था। WebAPI में केवल स्वैगर है। लेकिन स्वैगर सिर्फ टेक्स्ट है, और एक मित्र हर बार देखना चाहता है कि एपीआई कब बदलता है और क्या टूटता है। जब डब्ल्यूसीएफ था, तो उसने डब्ल्यूएसडीएल को सक्षम किया, अगर एपीआई में कल्पना बदल गई है, तो संकलन टूट गया।

यह कुछ समझ में आता है, क्योंकि यह खोज के लिए अनिच्छुक है, और संकलक मदद कर सकता है। Moq के साथ सादृश्य द्वारा, आप अपने ProductController के साथ GetResponse <> () विधि को सामान्य घोषित कर सकते हैं, और इस विधि में जाने वाले लंबोदर को नियंत्रक द्वारा मानकीकृत किया जाता है। यही है, जब आप लैम्ब्डा लिखना शुरू करते हैं, तो Ctrl + Space दबाएं और इस नियंत्रक के सभी तरीकों को देखें, बशर्ते कि एक पुस्तकालय हो, कोड के साथ dll हो। Intellisense है, यह सब लिखें जैसे कि आप नियंत्रक को बुला रहे हैं।

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

परावर्तन अनुकूलन

मेटा-प्रोग्रामिंग के बारे में सब कुछ परावर्तन के साथ बहुत कुछ है।



हम जानते हैं कि प्रतिबिंब धीमा है, मैं इससे बचना चाहूंगा। यहां, एक्सप्रेशन के साथ काम करने के अच्छे मामले भी हैं। पहला CreateInstance एक्टिवेटर है। आपको इसका उपयोग कभी भी नहीं करना चाहिए, क्योंकि एक्सप्रेशन.न्यू () है, जिसे आप बस एक लैम्ब्डा में ड्राइव कर सकते हैं, इसे संकलित कर सकते हैं, और फिर कंस्ट्रक्टर प्राप्त कर सकते हैं।



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



यही काम गेटर्स या सेटरों के साथ किया जा सकता है।



. - Fast Memember Fast Reflect, , . , , - . , , .



, , , . , , . , , - , , , , DSL, Little Languages -, .

ये सभी एक ही चीजें हैं जब कुछ कार्य के लिए हम आदेशों का एक सेट लेकर आते हैं और उसके लिए हम अपने स्वयं के दुभाषिया लिखते हैं जो इसे निष्पादित करता है। यही है, आवेदन के अंदर हम एक और संकलक या दुभाषिया लिखते हैं जो जानता है कि इन आदेशों का उपयोग कैसे करें। यह वही है जो DLR में किया जाता है, उस हिस्से में जो आयरनपाइथन, आयरनरुबी भाषाओं के साथ काम करता है। वहाँ अभिव्यक्ति पेड़ CLR में गतिशील कोड को निष्पादित करने के लिए प्रयोग किया जाता है। व्यापार अनुप्रयोगों में भी ऐसा ही किया जा सकता है, लेकिन अभी तक हमने इस तरह की आवश्यकता पर ध्यान नहीं दिया है और यह कोष्ठक के बाहर ही है।

परिणाम

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

पहला प्लस दिनचर्या को स्वचालित करने की क्षमता है। यदि आपके पास फ़िल्टरिंग, पेजिनेशन और उस सब के साथ 100 हजार नए साँचे हैं। मोजार्ट का एक मजाक था कि पासा, पर्याप्त समय और एक ग्लास रेड वाइन का उपयोग करके, आप किसी भी मात्रा में वॉल्टेज लिख सकते हैं। यहां एक्सप्रेशन ट्रीज़ की मदद से, थोड़ा मेटा-प्रोग्रामिंग, आप किसी भी मात्रा में फॉर्म लिख सकते हैं।

कोड की मात्रा बहुत कम हो जाती है, कोड पीढ़ी के विकल्प के रूप में, यदि आपको यह पसंद नहीं है, चूंकि आपको बहुत सारे कोड मिलते हैं, तो आप इसे नहीं लिख सकते हैं, रनटाइम में सब कुछ छोड़ दें।

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

दूसरी ओर, हम डिजाइनर की योग्यता के लिए आवश्यकताओं को बहुत बढ़ाते हैं, क्योंकि अभिव्यक्ति, प्रतिबिंब, उनके अनुकूलन के साथ काम करने के बारे में ज्ञान के सवाल आते हैं, उन स्थानों के बारे में जहां आप अपने आप को पैर में गोली मार सकते हैं। ऐसी कई बारीकियां हैं, इसलिए इस एपीआई से अपरिचित व्यक्ति तुरंत समझ नहीं पाएगा कि अभिव्यक्ति सिर्फ गठबंधन क्यों नहीं करती है। डिजाइनर कूलर होना चाहिए।

कुछ मामलों में, Expression.Compile () के माध्यम से, आप प्रदर्शन में गिरावट को पकड़ सकते हैं। कैशिंग उदाहरण में, मेरी एक सीमा थी कि अभिव्यक्तियाँ स्थिर हैं क्योंकि शब्दकोश का उपयोग कैशिंग के लिए किया जाता है। अगर किसी को नहीं पता कि यह आंतरिक रूप से कैसे व्यवस्थित किया गया है, तो वह बिना सोचे-समझे ऐसा करना शुरू कर देता है, विनिर्देशों को गैर-स्थिर घोषित करता है, कैश विधि काम नहीं करेगी, और हमें रैंडम स्थानों पर कंपाइल () में कॉल मिलेंगे। बिल्कुल वही जो मैं बचना चाहता था।

— C#-, , , Where(), - implicit- . MSDN, . , , , , , , StackOverflow , - .

, , . , , , . , — .

22-23 DotNext 2018 Moscow . , ( ).