प्रबंधित एक्स्टेंसिबिलिटी फ्रेमवर्क (MEF) और प्रबंधित AddIn फ्रेमवर्क (MAF, उर्फ System.AddIn) बहुत समान कार्यों को पूरा करने के लिए लगता है। इस ढेर अतिप्रवाह सवाल के अनुसार, MEF System.Addin के लिए एक प्रतिस्थापन है? , तुम भी एक ही समय में दोनों का उपयोग कर सकते हैं।
आप एक बनाम दूसरे का उपयोग कब करना चाहेंगे? आप किन परिस्थितियों में दोनों को एक साथ उपयोग करना पसंद करेंगे?
जवाबों:
मैं इन विकल्पों का मूल्यांकन कर रहा हूँ और यहाँ निष्कर्ष है कि मैं आया था।
MAF एक सच्चा ऐडऑन फ्रेमवर्क है। आप अपने एडोन को पूरी तरह से अलग कर सकते हैं, यहां तक कि उन्हें एक अलग ऐप डोमेन के अंदर भी चला सकते हैं ताकि अगर कोई ऐडऑन क्रैश हो जाए, तो यह आपके एप्लिकेशन को नीचे नहीं ले जाएगा। यह कुछ भी निर्भर करता है लेकिन अनुबंध आप उन्हें दे से addons decoupling का एक बहुत ही पूरा तरीका प्रदान करता है। वास्तव में, जब आप मुख्य ऐप को अपग्रेड कर रहे होते हैं, तो आप पुराने एडऑन्स को पश्चगामी अनुकूलता प्रदान करने के लिए अपने कॉन्ट्रैक्ट एडेप्टर का संस्करण बना सकते हैं। जबकि यह बहुत अच्छा लगता है, यह एक भारी कीमत के साथ आता है जिसे आपको एपिडेमेंस को पार करने के लिए भुगतान करना होगा। आप इस मूल्य को गति में और उन प्रकारों के लचीलेपन में भी भुगतान करते हैं जिन्हें आप आगे और पीछे भेज सकते हैं।
एमईएफ कुछ अतिरिक्त लाभों के साथ निर्भरता इंजेक्शन की तरह है, जैसे कि खोज क्षमता और ... (इस पर एक खाली ड्राइंग)। एमएएफ में अलगाव की डिग्री MEF में मौजूद नहीं है। वे दो अलग-अलग चीजों के लिए दो अलग-अलग ढांचे हैं।
डेनियल ने जो कहा वह अच्छा है। मैं जोड़ूंगा:
यदि आप System.Addins के बारे में वीडियो देखते हैं, तो वे स्पष्ट रूप से बहुत बड़ी परियोजनाओं के बारे में बात कर रहे हैं। उन्होंने कहा कि एक के बारे में बात टीम मेजबान आवेदन, एक और प्रबंध टीम प्रत्येक ऐडइन प्रबंध, और एक तीसरे दल अनुबंध और पाइप लाइन के प्रबंध। उसके आधार पर, मुझे लगता है कि System.Addins स्पष्ट रूप से बड़े अनुप्रयोगों के लिए है। मैं एसएपी जैसे ईआरपी सिस्टम जैसे एप्लिकेशन के बारे में सोच रहा हूं (शायद यह उतना बड़ा नहीं है, लेकिन आपको यह विचार मिलता है)। यदि आप उन वीडियो को देखते हैं तो आप बता सकते हैं कि System.Addins का उपयोग करने के लिए काम की मात्रा बहुत बड़ी है। अगर आपके पास अपने सिस्टम के लिए 3rd पार्टी ऐड-इन्स प्रोग्रामिंग करने वाली बहुत सारी कंपनियाँ हैं, तो यह अच्छी तरह से काम करेगा और आप उन एड-इन कॉन्ट्रैक्ट्स में से किसी को भी मौत की सजा के तहत नहीं तोड़ सकते।
दूसरी ओर, MEF SharpDevelop के ऐड-इन स्कीम, एक्लिप्स प्लगइन आर्किटेक्चर या मोनो.एडडिन्स में अधिक समानताएं साझा करता है। यह System.Addins की तुलना में समझना बहुत आसान है और मेरा मानना है कि यह बहुत अधिक लचीला है। आपके द्वारा खोई जाने वाली चीजें यह हैं कि आपको AppDomain अलगाव या MEF के साथ आउट-ऑफ-द-बॉक्स के मजबूत संस्करण अनुबंध नहीं मिलते हैं। MEF की ताकत यह है कि आप अपने संपूर्ण एप्लिकेशन को भागों की एक संरचना के रूप में संरचना कर सकते हैं, इसलिए आप अपने उत्पाद को अलग-अलग ग्राहकों के लिए अलग-अलग कॉन्फ़िगरेशन में शिप कर सकते हैं, और यदि ग्राहक कोई नई सुविधा खरीदता है, तो आप उस सुविधा के लिए भाग को उनकी इंस्टॉल निर्देशिका में छोड़ देते हैं और एप्लिकेशन इसे देखता है और इसे चलाता है। यह परीक्षण की सुविधा भी देता है। जिस वस्तु का आप परीक्षण करना चाहते हैं, उसकी वस्तु को तुरंत हटा सकते हैं और उसकी सभी निर्भरताओं के लिए नकली वस्तुओं को खिला सकते हैं,
सबसे महत्वपूर्ण बिंदु जो मैं उल्लेख करना चाहूंगा, वह यह है कि भले ही System.Addins पहले से ही फ्रेमवर्क में है, मुझे इसका उपयोग करने वाले लोगों के बहुत सारे सबूत नहीं दिखते हैं, लेकिन MEF कोडपलेक्स पर वहां बैठी है, जिसे माना जाता है .NET 4, और लोग पहले से ही इसके साथ बहुत सारे एप्लिकेशन बनाना शुरू कर रहे हैं (स्वयं शामिल)। मुझे लगता है कि आपको दो रूपरेखाओं के बारे में कुछ बताता है।
विकसित और MAF आवेदन भेज दिया। MAF पर मेरे विचार कुछ हद तक परेशान हैं।
MAF एक "डी-कपल" प्रणाली या सबसे खराब "शिथिल-युग्मित" प्रणाली है। MEF सर्वोत्तम रूप से "युग्मित" प्रणाली या "शिथिल-युगल" प्रणाली है।
MAF का उपयोग करके हमें एहसास हुआ कि MAF लाभ हैं:
एप्लिकेशन चल रहा है, जबकि नए या मौजूदा घटकों को अपडेट करना। जब एप्लिकेशन चल रहा था तब AddIn को अपडेट किया जा सकता था और उपयोगकर्ता को मूल रूप से अपडेट दिखाई देते थे। उसके लिए आपके पास AppDomains होना चाहिए।
खरीदे गए घटकों के आधार पर लाइसेंस। हम नियंत्रित कर सकते हैं कि कौन सा AddIn उपयोगकर्ता की भूमिका और अनुमतियों द्वारा लोड किया गया था और क्या AddIn को उपयोग के लिए लाइसेंस दिया गया था।
तीव्र विकास (तेज समय-से-बाज़ार)। AddIn विकास फुर्तीली कार्यप्रणाली के साथ पूरी तरह से फिट बैठता है, विकास टीम ने एक AddIn को एक बार में विकसित किया है, बाकी एप्लिकेशन के साथ एकीकरण टुकड़े को भी विकसित किए बिना।
बेहतर क्यूए (एक समय में केवल क्यूए एक घटक)। QA तब कार्यक्षमता का एक बिट के लिए दोषों का परीक्षण और निर्गमन कर सकता है। परीक्षण मामलों को विकसित करने और लागू करने के लिए आसान थे।
परिनियोजन (घटक जोड़ें जैसे वे विकसित और जारी किए जाते हैं और वे "बस काम करते हैं")। तैनाती केवल एक AddIn बनाने और फ़ाइल को स्थापित करने का मामला है। कोई अन्य विचार आवश्यक नहीं थे!
नए घटकों ने पुराने घटकों के साथ काम किया। AddIn कि काम पर रखा पर जल्दी विकसित किए गए थे। नया AddIns मूल रूप से अनुप्रयोग में फिट होता है
मेरे विचार में दो प्रौद्योगिकियां वास्तव में बहुत भिन्न उपयोग के मामलों को लक्षित करती हैं।
एमईएफ आम तौर पर एक शुद्ध निर्भरता इंजेक्शन परिदृश्य में सबसे अच्छा है, जहां अंतिम एकीकृत समाधान देने वाला व्यक्ति या समूह सब कुछ इकट्ठा कर रहा है और समग्र अखंडता के लिए वाउच कर रहा है, लेकिन मुख्य क्षमताओं के विभिन्न कार्यान्वयन करने की आवश्यकता है।
MAF एक ऐसे परिदृश्य के लिए है जहाँ कोई व्यक्ति / समूह एक प्लेटफ़ॉर्म या होस्ट विकसित कर रहा है और अन्य समूह इस तथ्य के बाद क्षमताओं को जोड़ेंगे और एक तरह से होस्ट समूह के नियंत्रण में नहीं होंगे। इस परिदृश्य में आवश्यकता अधिक विस्तृत तंत्र के लिए है ताकि मेजबान को दुष्ट ऐड-इन्स (या एक-दूसरे से ऐड-इन्स की रक्षा) से बचाया जा सके।
एक तीसरी समान-इन-पैटर्न तकनीक संपूर्ण प्रदाताबेस योजना है। यह भी एक क्षमता को बदलने में सक्षम बनाता है, लेकिन इसका लक्ष्य वास्तव में परिदृश्य है जहां मेजबान / ऐप को पूरी तरह से क्षमता की आवश्यकता होती है और कॉन्फ़िगरेशन के माध्यम से विभिन्न कार्यान्वयनों को निर्दिष्ट करने की आवश्यकता वास्तव में होती है।
मुझे यह लंबा लेख MAF और MEF दोनों पर चर्चा करते हुए मिला। http://emcpadden.wordpress.com/2008/12/07/managed-extensibility-framework-and-others/
अन्य उत्तरों द्वारा किए गए बिंदुओं के अलावा, ऐसा लगता है जैसे MEF और MAF के बीच एक महत्वपूर्ण अंतर यह है कि प्रबंधित एक्स्टेंसिबिलिटी फ्रेमवर्क एक स्वीकार्य भाग को दूसरे पर निर्भर करने की अनुमति देगा। उदाहरण के लिए, यह प्लग-इन को दूसरे प्लग-इन पर निर्भर होने देगा।
प्रबंधित एक्स्टेंसिबिलिटी फ्रेमवर्क भी वास्तव में होस्ट और ऐड-इन के बीच अंतर नहीं करता है, जैसा कि System.AddIn करता है। जहां तक MEF का सवाल है, वे सभी सिर्फ कंपोजेबल पार्ट्स हैं।
मेरी राय में, मतभेदों की खोज करने का सबसे अच्छा तरीका कुछ हाथों से कोड है। मुझे दो MSDN वॉकथ्रू मिले, दोनों एक कैलकुलेटर उदाहरण के साथ ताकि आप आसानी से उनके कार्यान्वयन की तुलना कर सकें:
MEF: MEF भागों का उपयोग करके सरल कैलकुलेटर उदाहरण
( M प्रबंधित ई xtensibility F rinson)
catalog.Catalogs.Add(new DirectoryCatalog("Plugins", "*.dll"));
का उपयोग करने catalog.Catalogs.Add(new
AssemblyCatalog(typeof(Program).Assembly));और निकालने के बजाय उपयोग करके उदाहरण को संशोधित कर सकते
हैं।)MEF को एक विशिष्ट निर्देशिका संरचना की आवश्यकता नहीं है, यह छोटी परियोजनाओं के लिए भी सरल और सरल है। यह विशेषताओं के साथ काम करता है, यह घोषित करने के लिए कि क्या निर्यात किया जाता है, जिसे पढ़ना और समझना आसान है। उदाहरण:
[Export(typeof(IOperation))]
[ExportMetadata("Symbol", '+')]
class Add: IOperation
{
public int Operate(int left, int right)
{
return left + right;
}
}
MEF स्वचालित रूप से वर्जनिंग से संबंधित नहीं है
MAF: V1 और V2 संस्करण के साथ सरल कैलकुलेटर MAF प्लगइन्स
( M प्रबंधित A ddin F rinson)
Pipeline AddIns CalcV1 CalcV2 AddInSideAdapters AddInViews Contracts HostSideAdapters
MEF और MAF दोनों .NET फ्रेमवर्क 4.x में शामिल हैं। यदि आप दो उदाहरणों की तुलना करते हैं, तो आप देखेंगे कि एमएएफ प्लगइन्स में एमईएफ फ्रेमवर्क की तुलना में बहुत अधिक जटिलता है - इसलिए आपको ध्यान से सोचने की आवश्यकता है कि उन फ्रेमवर्क का उपयोग कब करना है।
MAF और MEF दोनों AppDomains का उपयोग कर सकते हैं और दोनों रनटाइम में dll को लोड / अनलोड कर सकते हैं। हालाँकि मैंने जो अंतर पाया है वह हैं: MAF AddIns को डिकूप्ट किया गया है, MEF घटक ढीले हैं; एमएएफ "सक्रिय करता है" (नया उदाहरण) जबकि एमईएफ डिफ़ॉल्ट रूप से उदाहरण बनाता है।
एमईएफ के साथ आप जेनेरिक को किसी भी अनुबंध के लिए जेनरिक का उपयोग कर सकते हैं। इसका मतलब है कि MEF लोड / अनलोड और घटक प्रबंधन एक सामान्य पुस्तकालय में हो सकता है और उदारतापूर्वक उपयोग किया जा सकता है।