एमईएफ बनाम किसी भी आईओसी

Question

माइक्रोसॉफ्ट के प्रबंधित एक्सटेंसिबिलिटी फ्रेमवर्क (एमईएफ) और विभिन्न आईओसी कंटेनर (जैसे एकता) को देखते हुए, मैं यह देखने में असफल रहा कि दूसरे पर एक प्रकार का समाधान कब उपयोग करना है। अधिक विशेष रूप से, ऐसा लगता है MEF की तरह सबसे आईओसी प्रकार पैटर्न संभालती है और Unity जैसे एक आईओसी कंटेनर के रूप में आवश्यक नहीं होगा कि।

आदर्श रूप से, मैं एक अच्छा उपयोग केस देखना चाहता हूं जहां आईओसी कंटेनर का उपयोग एमईएफ के बजाय या इसके अतिरिक्त किया जाएगा।

Answer 1

जब नीचे उबला हुआ, मुख्य अंतर यह है कि आईओसी कंटेनर आम तौर पर स्थिर निर्भरता (संकलन समय पर जाना जाता है) के साथ सबसे अधिक उपयोगी हैं, और आम तौर पर MEF गतिशील निर्भरता (केवल रन-टाइम में जाना जाता है) के साथ सबसे अधिक उपयोगी है।

इस प्रकार, वे दोनों रचना इंजन हैं, लेकिन जोर प्रत्येक पैटर्न के लिए बहुत अलग है। डिजाइन निर्णय इस प्रकार जंगली रूप से भिन्न होते हैं, क्योंकि ज्ञात भागों के पंजीकरण के बजाय एमईएफ अज्ञात भागों की खोज के आसपास अनुकूलित किया जाता है।

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

इसके अलावा, @ पावेल निकोलोव के उत्तर में आलेख कुछ महान दिशा प्रदान करता है (यह ग्लेन ब्लॉक, एमईएफ के प्रोग्राम मैनेजर द्वारा लिखा गया है)।

Answer 2

मैं मानता हूँ कि MEF एक पूरी तरह से सक्षम आईओसी ढांचे हो सकता है। असल में मैं विस्तार और आईओसी दोनों के लिए एमईएफ का उपयोग करने के आधार पर एक आवेदन लिख रहा हूं। मैं इसके बारे में सामान्य भागों में ले लिया और यह एक "रूपरेखा" में बनाए और उन्हें खुला यह sourced के रूप में अपने स्वयं के ढांचे बुलाया SoapBox Core मामले में लोगों को देखने के लिए कि यह कैसे काम करता है चाहता हूँ।

विशेष रूप से, यदि आप एमईएफ को कार्रवाई में देखना चाहते हैं तो Host काम करता है।

Answer 3

मैं थोड़ी देर के लिए एमईएफ का उपयोग कर रहा हूं और आईओसी उत्पादों के बजाए इसका उपयोग करने के लिए महत्वपूर्ण कारक यह है कि हमारे पास नियमित रूप से हमारे प्लगइन निर्देशिका में दिए गए इंटरफ़ेस के 3-5 कार्यान्वयन होते हैं। उन कार्यान्वयनों में से कौन सा उपयोग किया जाना चाहिए वास्तव में ऐसा कुछ है जिसे केवल रनटाइम पर ही तय किया जा सकता है।

MEF दे ठीक यही करने में अच्छा है। आमतौर पर, आईओसी सुनिश्चित करें कि आप भविष्य में कुछ बिंदु पर ORM उत्पाद 2 के लिए ORM उत्पाद 1 के आधार पर एक IUserRepository, बाहर स्वैप सकता है एक cononical उदाहरण के लिए, बनाने की ओर है। हालांकि, अधिकांश आईओसी समाधान मानते हैं कि किसी दिए गए समय पर केवल एक IUserRepository ही प्रभावी होगा।

यदि, आपको किसी दिए गए पृष्ठ अनुरोध के लिए इनपुट डेटा के आधार पर एक को चुनने की आवश्यकता है, तो आईओसी कंटेनर आम तौर पर हानि पर होते हैं।

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

इस प्रकार की शक्ति हमें प्लगइन के लिए गिरावट ओवरराइड को परिभाषित करने देती है। जिन ऐप्स पर मैं काम कर रहा हूं वे वास्तव में 30+ कार्यान्वयन के लिए तैनात एक ही कोडबेस हैं। इसलिए, हम आमतौर पर प्लगइन की तलाश कर रहे हैं:

1. एक इंटरफ़ेस कार्यान्वयन जो वर्तमान साइट के लिए विशिष्ट है और विशिष्ट रिकॉर्ड प्रकार में प्रश्न है।
2. एक इंटरफ़ेस कार्यान्वयन जो वर्तमान साइट के लिए विशिष्ट है, लेकिन किसी भी प्रकार के रिकॉर्ड के साथ काम करता है।
3. एक इंटरफ़ेस जो किसी भी साइट और किसी भी रिकॉर्ड के लिए काम करता है।

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

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

Answer 4

मैं ऑफ-विषय होने के लिए क्षमा चाहता हूं।

• यह विशेषता आधारित जो मदद करने के लिए किसी भी अच्छा नहीं करता है आप के रूप में वे करते हैं यही कारण है कि चीजें काम पता लगाना है: मैं बस 2 खामियों कि MEF एक अनावश्यक जटिलता प्रस्तुत करना देखते हैं कि कहने के लिए करना चाहता था। ढांचे के आंतरिक भाग में ब्योरे के विवरण प्राप्त करने का कोई तरीका नहीं है यह देखने के लिए कि वहां वास्तव में क्या चल रहा है। ट्रेसिंग लॉग प्राप्त करने या हल करने वाले तंत्र को हुक करने और मैन्युअल रूप से अनसुलझे स्थितियों को संभालने का कोई तरीका नहीं है

• इसमें कुछ हिस्सों को अस्वीकार करने के कारणों का पता लगाने के लिए कोई समस्या निवारण तंत्र नहीं है। एक असफल हिस्से पर इशारा करते हुए यह आपको नहीं बताता कि वह हिस्सा क्यों विफल रहा है।

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