Managed Extensibility Framework (MEF) e Managed AddIn Framework (MAF, aka System.AddIn) sembrano svolgere compiti molto simili. Secondo questa domanda Stack Overflow, MEF è un sostituto di System.Addin? , puoi persino usarli entrambi contemporaneamente.
Quando sceglieresti di usare l'uno contro l'altro? In quali circostanze sceglieresti di usarli entrambi insieme?
Risposte:
Ho valutato queste opzioni ed ecco la conclusione a cui sono arrivato.
MAF è un vero framework di addon. Puoi separare completamente i tuoi componenti aggiuntivi, anche eseguendoli all'interno di un dominio app separato in modo che se un componente aggiuntivo si blocca, non eliminerà l'applicazione. Fornisce anche un modo molto completo di disaccoppiare gli addon a seconda di qualsiasi cosa tranne il contratto che gli dai. In effetti, puoi aggiornare le versioni dei tuoi adattatori di contratto per garantire la retrocompatibilità con i vecchi componenti aggiuntivi durante l'aggiornamento dell'app principale. Anche se questo suona alla grande, viene fornito con un prezzo pesante che devi pagare per attraversare gli appdomain. Paghi questo prezzo in velocità e anche nella flessibilità dei tipi che puoi inviare avanti e indietro.
MEF è più simile all'iniezione di dipendenza con alcuni vantaggi aggiuntivi come la rilevabilità e ... (tracciando uno spazio vuoto su questo). Il grado di isolamento che MAF ha non è presente in MEF. Sono due quadri diversi per due cose diverse.
Ciò che Danielg ha detto è buono. Aggiungerei:
Se guardi i video su System.Addins, stanno chiaramente parlando di progetti molto grandi. Parla di un team che gestisce l'applicazione host, un altro team che gestisce ciascun componente aggiuntivo e un terzo team che gestisce il contratto e la pipeline. Sulla base di ciò, penso che System.Addins sia chiaramente per applicazioni più grandi. Sto pensando ad applicazioni come i sistemi ERP come SAP (forse non così grande, ma hai avuto l'idea). Se hai guardato quei video puoi dire che la quantità di lavoro per usare System.Addins è molto grande. Funzionerebbe bene se tu avessi un sacco di aziende che programmano componenti aggiuntivi di terze parti per il tuo sistema e non riesci a rompere nessuno di quei contratti di componenti aggiuntivi a pena di morte.
D'altra parte, MEF sembra condividere più somiglianze con lo schema del componente aggiuntivo di SharpDevelop, l'architettura del plugin Eclipse o Mono.Addins. È molto più facile da capire rispetto a System.Addins e credo che sia molto più flessibile. Le cose che perdi sono che non ottieni l'isolamento di AppDomain o contratti di versioning pronti all'uso con MEF. I punti di forza di MEF sono che puoi strutturare la tua intera applicazione come una composizione di parti, in modo da poter spedire il tuo prodotto in diverse configurazioni per diversi clienti e se il cliente acquista una nuova funzione, devi semplicemente rilasciare la parte per quella funzione nella loro directory di installazione e l'applicazione lo vede e lo esegue. Facilita anche i test. Puoi istanziare l'oggetto che vuoi testare e dargli da mangiare oggetti finti per tutte le sue dipendenze,
Il punto più importante che vorrei menzionare è che anche se System.Addins è già nel framework, non vedo molte prove di persone che lo usano, ma MEF è semplicemente seduto su CodePlex presumibilmente incluso in .NET 4 e le persone stanno già iniziando a creare molte applicazioni (incluso me stesso). Penso che ti dica qualcosa sui due quadri.
Dopo aver sviluppato e spedito un'applicazione MAF. Le mie opinioni su MAF sono in qualche modo logore.
MAF è un sistema "disaccoppiato" o, nel peggiore dei casi, un sistema "non accoppiato". MEF è il sistema "accoppiato" o il sistema "a coppie libere" nella migliore delle ipotesi.
I vantaggi di MAF che abbiamo realizzato utilizzando MAF sono:
Installazione di nuovi componenti o aggiornamento di componenti esistenti mentre l'applicazione è in esecuzione. Il componente aggiuntivo può essere aggiornato mentre l'applicazione era in esecuzione e gli aggiornamenti vengono visualizzati all'utente senza soluzione di continuità. Devi avere AppDomains per questo.
Licenze basate sui componenti acquistati. Potremmo controllare quali componenti aggiuntivi sono stati caricati dal ruolo e dalle autorizzazioni dell'utente e se il componente aggiuntivo è stato concesso in licenza per l'uso.
Sviluppo rapido (time-to-market più rapido). Lo sviluppo di AddIn si adatta perfettamente alla metodologia Agile, il team di sviluppo ha sviluppato un AddIn alla volta senza dover sviluppare anche il pezzo di integrazione con il resto dell'applicazione.
QA migliorato (solo QA un componente alla volta). Il QA potrebbe quindi testare ed emettere difetti per un singolo bit di funzionalità. I casi di test erano più facili da sviluppare e implementare.
Distribuzione (aggiungi componenti man mano che vengono sviluppati e rilasciati e "funzionano"). La distribuzione è solo una questione di creazione di un componente aggiuntivo e installazione del file. Non erano necessarie altre considerazioni!
Nuovi componenti hanno funzionato con vecchi componenti. AddIn che sono stati sviluppati all'inizio hanno continuato a funzionare. I nuovi componenti aggiuntivi si adattano perfettamente all'applicazione
Dal mio punto di vista, le due tecnologie in realtà mirano a casi d'uso molto diversi.
MEF è in genere il migliore in uno scenario di iniezione di pura dipendenza in cui la persona o il gruppo che fornisce la soluzione integrata finale sta assemblando tutto e garantendo l'integrità generale, ma ha bisogno di avere implementazioni diverse delle funzionalità chiave.
MAF è per uno scenario in cui qualcuno / gruppo sta sviluppando una piattaforma o un host e altri gruppi aggiungeranno capacità dopo il fatto e in un modo non sotto il controllo del gruppo host. In questo scenario è necessario disporre di meccanismi più elaborati per "proteggere" l'host da componenti aggiuntivi non autorizzati (o per proteggere componenti aggiuntivi l'uno dall'altro).
Una terza tecnologia simile nel modello è l'intero schema ProviderBase. Ciò consente anche di sostituire una funzionalità, ma il suo obiettivo è davvero lo scenario in cui l'host / app ha assolutamente bisogno di una funzionalità e la necessità è quella di specificare diverse implementazioni tramite la configurazione.
Ho appena trovato questo lungo articolo che parla sia di MAF che di MEF. http://emcpadden.wordpress.com/2008/12/07/managed-extensibility-framework-and-others/
Oltre ai punti sollevati dalle altre risposte, sembra che una delle differenze chiave tra MEF e MAF sia che il Managed Extensibility Framework consentirebbe a una parte componibile di dipendere da un'altra. Permetterebbe ad un plug-in di dipendere da un altro plug-in, ad esempio.
Managed Extensibility Framework inoltre non fa distinzioni tra l'host e il componente aggiuntivo, come fa System.AddIn. Per quanto riguarda MEF, sono solo parti componibili.
A mio avviso, il modo migliore per scoprire le differenze è un codice pratico. Ho trovato due procedure dettagliate di MSDN, entrambe con un esempio di calcolatrice in modo da poter confrontare facilmente le loro implementazioni:
MEF: Esempio Calcolatore semplice utilizzando parti del MEF
( M anaged E xtensibility F QUADRO)
catalog.Catalogs.Add(new DirectoryCatalog("Plugins", "*.dll"));
invece di usare catalog.Catalogs.Add(new
AssemblyCatalog(typeof(Program).Assembly));ed estrarre il codice della calcolatrice e il contratto per separare i progetti DLL.)MEF non ha bisogno di avere una struttura di directory specifica, è semplice e diretto da usare, anche per piccoli progetti. Si lavora con gli attributi, a dichiarare ciò che viene esportato, che è facile da leggere e capire. Esempio:
[Export(typeof(IOperation))]
[ExportMetadata("Symbol", '+')]
class Add: IOperation
{
public int Operate(int left, int right)
{
return left + right;
}
}
MEF non si occupa automaticamente del controllo delle versioni
MAF: calcolatrice semplice con V1 e V2 versione plugin MAF
( M anaged A DDIN F QUADRO)
Pipeline AddIns CalcV1 CalcV2 AddInSideAdapters AddInViews Contracts HostSideAdapters
Sia MEF che MAF sono inclusi in .NET Framework 4.x. Se si confrontano i due esempi, si noterà che i plug-in MAF presentano una complessità molto maggiore rispetto al framework MEF, quindi è necessario riflettere attentamente su quando utilizzare quale di questi framework.
MAF e MEF possono entrambi usare AppDomains ed entrambi possono caricare / scaricare dll in runtime. Tuttavia le differenze che ho riscontrato sono: i componenti aggiuntivi MAF sono disaccoppiati, i componenti MEF sono accoppiati sfusi; MAF "Attiva" (nuova istanza) mentre MEF crea istanze per impostazione predefinita.
Con MEF puoi usare Generics per creare GenericHost per qualsiasi contratto. Ciò significa che il carico / scarico MEF e la gestione dei componenti possono essere in una libreria comune e utilizzati genericamente.