अब, मैं गड़बड़ कर रहा हूं। मैं उन सभी को मिला सकता हूं। मैं मजबूत कोड और स्थिर पद्धति बनाना चाहता हूं, मुझे क्या उपयोग करना चाहिए?एओपी बनाम एमवीसी फ़िल्टरएट्रिब्यूट बनाम इंटरसेप्टर्स
यह सब अच्छा एप्लिकेशन डिज़ाइन के साथ शुरू होता है। जब आपके आवेदन का डिज़ाइन सही होता है, तो उन एओपी के साथ बातचीत करने के लिए आपके लिए बहुत कम कारण होगा, जो आपके यूआई फ्रेमवर्क का खुलासा करते हैं (यह डब्ल्यूसीएफ के लिए भी है)।
उदाहरण के लिए जब आप एक सामान्य इंटरफ़ेस के पीछे सभी व्यावसायिक तर्क छिपाते हैं, और इसे कमांड संदेश भेजते हैं (जैसा कि this article में दिखाया गया है), तो आपके नियंत्रक पतले रैपर बन जाएंगे जो अक्सर इस तरह के व्यवसाय कमांड को निष्पादित करने से अधिक नहीं करते हैं। उस स्थिति में आप उन व्यावसायिक परिचालनों को लपेटकर प्राधिकरण और अपवाद फ़िल्टरिंग को कार्यान्वित करने में सक्षम होंगे, जिससे यूआई कोड साफ और विशेषताओं से मुक्त हो जाएगा। व्यवसाय संचालन के आसपास उन क्रॉस-कटिंग चिंताओं को लपेटना दोनों हस्तक्षेप या plain old decorators के साथ किया जा सकता है। यह आपको अधिक लचीलापन देता है और आपके डिजाइन को SOLID रखता है (जिसमें बहुत कम स्पष्ट दीर्घकालिक लाभ हैं)।
हालांकि पोस्टशर्प के रूप में कोड बुनाई उपकरण का उपयोग होता है, तो आपको उनके साथ सावधान रहना चाहिए। वे एक पोस्ट-संकलन प्रक्रिया का उपयोग कर आपकी असेंबली में कोड इंजेक्ट करते हैं। यह उन पहलुओं को मारने के बिना उन कक्षाओं का परीक्षण करने के लिए इकाई को बहुत दर्दनाक बनाता है। आप अलगाव में उन वर्गों का आसानी से परीक्षण नहीं कर सकते (जो इकाई परीक्षण के लिए एक पूर्व शर्त है)। कुछ स्थिर चर पर निर्भर अपने पहलुओं को बनाने, दोनों पहलुओं और इकाई परीक्षणों को जटिल बनाता है। स्टेटिक वैरिएबल समानांतर में यूनिट परीक्षण चलाने में कठोर बनाता है और वैश्विक स्थिरांक के उपयोग के लिए अन्य परीक्षणों को प्रभावित होने से रोकने के लिए बदले गए वैश्विक सेटिंग को सही ढंग से फाड़ने के लिए परीक्षणों की आवश्यकता होगी।
हालांकि कोड बुनाई उपकरण का परिणाम प्रदर्शन में होता है जो अक्सर अवरोध से अधिक होता है, सजावट के उपयोग की तुलना में कोई प्रदर्शन लाभ नहीं होता है।
आपने तीन तकनीकों का हवाला दिया है जो सभी ऐसा करने का इरादा रखते हैं: मौजूदा कोडबेस को कार्यान्वित किए बिना कार्यक्षमता जोड़ें।
ASP.NET MVC और डि दोनों पर सीमाओं डाल आप पहलुओं (नाम फिल्टर या इंटरसेप्टर) हो सकता है जहां क्योंकि प्रौद्योगिकी केवल कुछ स्थानों पर व्यवहार जोड़ने में सक्षम है, यह देखते हुए वे अपने कोड को संपादित नहीं कर सकते। केवल पोस्टरहर्प जैसी कंपाइलर-आधारित प्रौद्योगिकियों में हर जगह पहलुओं को जोड़ने की क्षमता है। हालांकि, सभी तीन एओपी अवधारणाओं के कार्यान्वयन हैं।
पहलुओं ने कई उपयोग मामलों में पारंपरिक ऑब्जेक्ट उन्मुख प्रोग्रामिंग पर लाभ साबित किए हैं। यह सच नहीं है कि पारंपरिक ओओपी द्वारा एक ही कीमत पर बेहतर डिजाइन के साथ हर एक समस्या हल की जा सकती है। हालांकि, यह सही है कि एओपी मुख्यधारा नहीं है, और गैर-मुख्यधारा प्रौद्योगिकी का उपयोग करने के लिए लागत और जोखिम हैं (एओपी का जन्म 90 के दशक में हुआ था और 60 के दशक में ओओपी)। किसी भी नवाचार के साथ, विभिन्न कलाकारों के जोखिम और लाभ के बीच अलग-अलग संवेदनशीलता होती है, इसलिए जल्दी या देर से गोद लेने वाले बन सकते हैं।
एओपी इकाई परीक्षण में बाधा नहीं है, लेकिन इस विषय पर थोड़ा साझा अनुभव नहीं है। आम तौर पर, पहलुओं को कोड की अलग इकाइयों के रूप में परीक्षण किया जाना चाहिए। आवश्यक और अनिवार्य पहलू हैं।आम तौर पर, व्यावसायिक कोडों को आवश्यक पहलुओं के साथ परीक्षण किया जाना चाहिए, लेकिन गैर-आवश्यक पहलुओं को अक्षम किया जाना चाहिए। आप बिल्ड समय पर स्थिर रूप से पहलुओं को अक्षम कर सकते हैं (केवल बिल्ड कॉन्फ़िगरेशन से कुछ पहलू को बाहर कर सकते हैं), या रन टाइम पर (कुछ स्थैतिक चर पर निर्भर पहलू को बनाते हैं जिसे आपने परीक्षण के दौरान गलत पर सेट किया है)।
क्या आप किसी भी लेख का संदर्भ दे सकते हैं जो अधिक विस्तार से बताता है कि आवश्यक और अनिवार्य पहलू क्या हैं? – Steven
@Steven मेरे पास एक ही लेख नहीं है। गैर-आवश्यक पहलू की अवधारणा को वास्तव में अकादमिक साहित्य में "हानिरहित सलाह" नाम दिया गया है। इसका मतलब है कि पहलू अपने लक्ष्य (बेस कोड) के लिए पूरी तरह से ऑर्थोगोनल है और इसके परिणाम को प्रभावित किए बिना हटाया जा सकता है। उदाहरण के लिए, लॉगिंग और प्रदर्शन निगरानी हानिरहित हैं, लेकिन लेनदेन हैंडलिंग या INotifyPropertyChanged नहीं हैं। –
देखें [इस प्रस्तुति में स्लाइड 12] (http://www.dantasfiles.com/daniel/research/Harmless%20Advice%20 (मूर्ख)% 20Slides.pdf) –
समय इंजेक्शन संकलन इकाई परीक्षण के साथ हस्तक्षेप कैसे करता है? आप संकलित किए बिना यूनिट परीक्षण भी नहीं करेंगे? – jfar
@jfar: संकलन के दौरान पहलुओं के साथ आपका उत्पादन कोड एक साथ बुना हुआ है। इसके कारण आप अलगाव में अब अपने उत्पादन कोड का परीक्षण नहीं कर सकते हैं। जब एक यूनिट टेस्ट कुछ उत्पादन कोड को कॉल करता है, तो पहलुओं को हमेशा लागू किया जाएगा। वास्तव में, आप इकाई परीक्षण नहीं कर सकते हैं, क्योंकि परिभाषा के अनुसार एक इकाई परीक्षण अलगाव में चलता है। आपके पास एकीकरण परीक्षण होगा। अब अपने डाउनवोट को पूर्ववत करना पसंद है? – Steven
आपका कोड हमेशा संकलक द्वारा उत्पादन किया जाता है, उत्पादन और इकाई परीक्षण संभवतः कंपाइलर द्वारा विभिन्न संस्करण प्राप्त कर सकता है ताकि सजावटी या डी या कुछ भी हो। इस जवाब में दोष यह है कि एओपी या पोस्टशर्प यूनिट परीक्षण को किसी अद्वितीय या उल्लेखनीय तरीके से प्रभावित नहीं करता है। – jfar