MEF और MAF (System.AddIn)

Question

के बीच चुनना प्रबंधित तानाना फ्रेमवर्क (MEF) और प्रबंधित ऐडइन फ्रेमवर्क (MAF, उर्फ ​​System.AddIn) बहुत समान कार्यों को पूरा करने लगते हैं। इस स्टैक ओवरफ़्लो प्रश्न के अनुसार, Is MEF a replacement for System.Addin?, आप एक ही समय में दोनों का उपयोग भी कर सकते हैं।

जब आप एक अन्य बनाम का उपयोग करना चुनते हैं? आप किन स्थितियों के साथ दोनों परिस्थितियों का उपयोग करना चुनेंगे?

Answer 1

मैं इन विकल्पों का मूल्यांकन किया गया है और यहाँ निष्कर्ष यह है कि मैं करने के लिए आया है।

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

MEF अधिक इस तरह के खोजे जाने और के रूप में कुछ अतिरिक्त लाभ के साथ निर्भरता इंजेक्शन ... (यह एक पर एक खाली ड्राइंग) की तरह है। एमईएफ में एमएएफ मौजूद नहीं है अलगाव की डिग्री। वे दो अलग-अलग चीजों के लिए दो अलग-अलग ढांचे हैं।

Answer 2

डैनियल ने क्या कहा अच्छा है। मैं जोड़ना होगा:

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

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

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

Answer 3

मेरे विचार में दो तकनीकें वास्तव में बहुत अलग उपयोग मामलों को लक्षित करती हैं।

एमईएफ आमतौर पर एक शुद्ध निर्भरता इंजेक्शन परिदृश्य में सबसे अच्छा है जहां अंतिम एकीकृत समाधान प्रदान करने वाला व्यक्ति या समूह समग्र सब कुछ के लिए सब कुछ इकट्ठा कर रहा है और मुख्य क्षमताओं के विभिन्न कार्यान्वयन की आवश्यकता है।

एमएएफ एक परिदृश्य के लिए है जहां कोई/समूह मंच या मेजबान विकसित कर रहा है और अन्य समूह इस तथ्य के बाद क्षमताओं को जोड़ देंगे और एक तरह से मेजबान समूह के नियंत्रण में नहीं होंगे। इस परिदृश्य में मेजबान को नकली ऐड-इन्स (या एक-दूसरे से ऐड-इन्स की रक्षा करने के लिए) को "सुरक्षित" करने के लिए अधिक विस्तृत तंत्र के लिए आवश्यकता है।

एक तीसरी समान-इन-पैटर्न तकनीक पूरी प्रदाताबेस योजना है। यह एक क्षमता को बदलने में भी सक्षम बनाता है लेकिन इसका लक्ष्य वास्तव में परिदृश्य है जहां होस्ट/ऐप को पूरी तरह से क्षमता की आवश्यकता होती है और आवश्यकता वास्तव में कॉन्फ़िगरेशन के माध्यम से विभिन्न कार्यान्वयन निर्दिष्ट करने की आवश्यकता होती है।

Answer 4

मुझे अभी एमएएफ और एमईएफ दोनों पर चर्चा करने वाला यह लंबा लेख मिला है। http://emcpadden.wordpress.com/2008/12/07/managed-extensibility-framework-and-others/

अन्य उत्तर द्वारा किए गए अंक के अलावा, यह लग रहा है जैसे कि MEF और MAF के बीच मुख्य अंतर में से एक है कि प्रबंधित तानाना फ्रेमवर्क एक composable भाग एक और पर निर्भर करने की अनुमति होगी। यह एक प्लग-इन को अन्य प्लग-इन पर निर्भर करता है, उदाहरण के लिए।

प्रबंधित एक्सटेंसिबिलिटी फ्रेमवर्क भी मेजबान और एड-इन के बीच सिस्टम के रूप में भेद नहीं करता है। AddIn करता है। जहां तक ​​एमईएफ का संबंध है, वे सभी सिर्फ संगत भागों हैं।

Answer 5

एमएएफ आवेदन विकसित और भेजकर। एमएएफ पर मेरे विचार कुछ हद तक जादुई हैं।

एमएएफ सबसे खराब पर "डी-युग्मित" प्रणाली या "ढीला-युग्मित" प्रणाली है। एमईएफ सबसे अच्छा "युग्मित" प्रणाली या "ढीला-जोड़ा" प्रणाली है।

MAF लाभ है कि हम MAF का उपयोग करके एहसास हुआ हैं:

1. नए स्थापित कर रहा है या जब आवेदन चल रहा है मौजूदा घटकों को अद्यतन करने। ऐडइन अपडेट किया जा सकता था जब एप्लिकेशन चल रहा था और अद्यतन उपयोगकर्ता को निर्बाध रूप से दिखाई देते हैं। इसके लिए आपको AppDomains रखना होगा।

2. खरीदे गए घटकों के आधार पर लाइसेंसिंग। हम नियंत्रित कर सकते हैं कि कौन सा ऐडइन उपयोगकर्ता की भूमिका और अनुमतियों द्वारा लोड किया गया था और क्या ऐडइन को उपयोग के लिए लाइसेंस प्राप्त किया गया था।

3. रैपिड डेवलपमेंट (तेज़ समय-दर-बाज़ार)। एडइन विकास पूरी तरह से Agile methodolgy के साथ फिट बैठता है, विकास दल ने एक समय में एक ऐडइन विकसित किया है, बिना किसी एप्लिकेशन के एकीकरण टुकड़े को विकसित किए।

4. बेहतर क्यूए (एक समय में केवल क्यूए एक घटक)। क्यूए फिर परीक्षण की एक बिट बिट के लिए परीक्षण और दोष जारी कर सकता है। परीक्षण के मामलों को विकसित करना और कार्यान्वित करना आसान था।

5. परिनियोजन (घटक को विकसित और जारी किए जाने के रूप में जोड़ें और वे "बस काम करें")। परिनियोजन केवल ऐडइन बनाने और फ़ाइल को स्थापित करने का मामला है। कोई अन्य विचार जरूरी नहीं था!

6. नए घटक पुराने घटकों के साथ काम करते थे। AddIn जो काम पर रखा शुरू में विकसित किया गया था।नई AddIns आवेदन मूल

Answer 6

मेरी राय में में फिट, मतभेद को खोजने के लिए सबसे अच्छा तरीका है कुछ हाथ कोड है।

MEF: ताकि आप आसानी से उनके कार्यान्वयन की तुलना कर सकते मैं दो MSDN walkthroughs, एक कैलकुलेटर उदाहरण के साथ दोनों पायाSimple calculator example using MEF parts
(एम anaged ई xtensibility एफ ramework)

• दिखाता है कि एमईएफ प्रौद्योगिकी का उपयोग करके एक सरल कैलकुलेटर कैसे बनाया जाए। बाहरी डीएलएस को लोड करने का तरीका नहीं दिखाता है। (लेकिन आप बस catalog.Catalogs.Add(new DirectoryCatalog("Plugins", "*.dll")); का उपयोग कर के बजाय catalog.Catalogs.Add(new AssemblyCatalog(typeof(Program).Assembly)); का उपयोग कर और अलग DLL परियोजनाओं के लिए कैलकुलेटर कोड और अनुबंध निकालने से उदाहरण संशोधित कर सकते हैं।)

• MEF एक विशिष्ट निर्देशिका संरचना के लिए की जरूरत नहीं है, यह है छोटी परियोजनाओं के लिए भी उपयोग करने के लिए सरल और सीधा। यह गुणों के साथ काम करता है, निर्यात करने के लिए घोषित करने के लिए, जो पढ़ने और समझने में आसान है। उदाहरण: [Export(typeof(IOperation))] [ExportMetadata("Symbol", '+')] class Add: IOperation { public int Operate(int left, int right) { return left + right; } }

• MEF स्वचालित रूप से संस्करण के साथ सौदा नहीं है

MAF:Simple calculator with V1 and V2 version MAF plugins
(एमanaged एक ddin एफ ramework)

• दिखाता है कि वी 1 प्लगइन का उपयोग करके कैलकुलेटर कैसे बनाया जाए और फिर पीछे की संगतता बनाए रखने के दौरान वी 2 प्लगइन पर कैसे स्थानांतरित किया जाए (नोट: आप प्लगइन here प्लगइन का V2 संस्करण पा सकते हैं, लिंक में मूल लेख टूट गया है)
• MAF लागू करता एक विशिष्ट निर्देशिका संरचना, और यह है, यह काम करने के लिए बॉयलरप्लेट कोड का एक बहुत जरूरत इसलिए मैं छोटी परियोजनाओं के लिए यह सलाह नहीं देते। उदाहरण:

  Pipeline 
      AddIns 
      CalcV1 
      CalcV2 
      AddInSideAdapters 
      AddInViews 
      Contracts 
      HostSideAdapters 
  

दोनों MEF और MAF .नेट फ्रेमवर्क 4.x. में शामिल किए गए हैं यदि आप दो उदाहरणों की तुलना करते हैं तो आप देखेंगे कि एमएएफ प्लगइन्स के पास एमईएफ ढांचे की तुलना में बहुत अधिक जटिलता है - इसलिए आपको उन ढांचे का उपयोग करने के लिए ध्यान से सोचने की आवश्यकता है।

Answer 7

एमएएफ और एमईएफ दोनों ऐपडोमेन्स का उपयोग कर सकते हैं और दोनों रनटाइम में डीएल लोड/अनलोड कर सकते हैं। हालांकि मुझे जो मतभेद मिले हैं वे हैं: एमएएफ एडिन्स decoupled हैं, एमईएफ घटक ढीले युग्मित हैं; एमएएफ "सक्रिय" (नया उदाहरण) जबकि एमईएफ डिफ़ॉल्ट रूप से उदाहरण बनाता है।

MEF के साथ आप किसी भी अनुबंध के लिए GenericHost बनाने के लिए जेनेरिक्स उपयोग कर सकते हैं। इसका मतलब है कि एमईएफ लोड/अनलोड और घटक प्रबंधन एक सामान्य पुस्तकालय में हो सकता है और सामान्य रूप से उपयोग किया जा सकता है।