AOP और PostSharp के साथ मेरा अनुभव

एक बार, मैंने PostSharp पर काफी अच्छी तरह से शोध किया और यहां तक ​​कि अपने विकास के उद्देश्यों के लिए इसका इस्तेमाल करना शुरू कर दिया। मैंने इस विषय पर एक पेंचकस और कुछ लेख लिखने में भी कामयाबी हासिल की। दुर्भाग्य से, PostSharp के साथ, मैंने बाद में इस विषय पर समुदाय से आवधिक पूछताछ के कारणों के लिए बिल्कुल भी काम नहीं किया? क्यों? ”, मैंने सभी i को डॉट करने के लिए इस पोस्ट को लिखने का फैसला किया।

एक पनीर में मुफ्त पनीर

PostSharp आपको IL को पुनर्लेखन करके मौजूदा कोड में कार्यक्षमता छड़ी करने की अनुमति देता है। यह विचार नया कुछ भी नहीं है, और MSBuild-th Task लिखने के लिए जो ILDASM करेगा, IL में कुछ परिवर्तन करेगा, और फिर ILASM करेगा - कार्य काफी तुच्छ है। एक समय, मैंने विधानसभा से पर्यवेक्षकों से मेटाडेटा को हटाने के लिए सिर्फ इतना किया। (यह अभी भी मेरे लिए एक रहस्य है कि पर्यवेक्षक जानबूझकर पटाखों को यह बताने में मदद क्यों करते हैं कि वास्तव में उनका क्या उपयोग किया गया था।)

PostSharp का सार यह है कि आप घोषित रूप से ले सकते हैं और चिह्नित कर सकते हैं, उदाहरण के लिए, एक विधि, कह रही है कि प्रत्येक कॉल एक अलग धागे में होगी:

[WorkerThread] public void MyMethod() { ⋮ } 

पोस्टकम्प्लीशन की प्रक्रिया में PostSharp इस विधि को लेता है और इसे फिर से लिखता है, कुछ Task.Factory.StartNew(() => { /* */ }); साथ एक साधारण विधि कॉल को प्रतिस्थापित करता है। Task.Factory.StartNew(() => { /* */ }); । यह अच्छा लग रहा है और, ईमानदार होने के लिए, यह काम करता है।

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

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

नशे का प्रभाव

मेरे पास [NotifyPropertyChanged] विशेषता के साथ चिह्नित एक विशाल वर्ग था - मुझे लगता है कि आप पहले से ही समझ गए थे कि वह क्या कर रहा था। और सब कुछ उतना ही अच्छा होगा, लेकिन व्यवहार में कई चीजें मुझे परेशान करती हैं।

सबसे पहले, पहलू के माध्यम से INotifyPropertyChanged को लागू करने के लिए कोड अद्भुत था - यह इतना जटिल और अपठनीय था कि मुझे जरूरत होने पर भी इसे छूने से डर लगता था।

दूसरे, ऑब्जेक्ट ने ही संकलन चरण में INotifyPropertyChanged को लागू नहीं किया और, तदनुसार, इस इंटरफ़ेस तक पहुंच को एक डबल कास्ट के माध्यम से फीका करना पड़ा।

तीसरा, विशेषता दृष्टिकोण सब-या-कुछ नहीं था। उदाहरण के लिए, मैं पढ़ने-लिखने की संपत्तियों के लिए सूचनाएं प्राप्त कर सकता था, लेकिन जब मैंने NotifyPropertyChanged() को केवल उस पर निर्भर प्रॉपर्टी पर NotifyPropertyChanged() उत्पन्न करने के लिए संपत्ति को बदलना चाहा, तो समस्याएं शुरू हो NotifyPropertyChanged() ।

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

वैकल्पिक?

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

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

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

वह सब है। कृपया ध्यान दें कि AOP / PostSharp के लिए मेरा दृष्टिकोण सिर्फ मेरी निजी राय है। अगर सब कुछ आपके लिए काम करता है - यह सुपर है, तो इसके बारे में लिखें! ■