Scelta tra MEF e MAF (System.AddIn)

Question

Il Managed Extensibility Framework (MEF) e Managed AddIn Framework (MAF, ovvero System.AddIn) sembrano svolgere compiti molto simili. In base a questa domanda di Overflow dello stack, Is MEF a replacement for System.Addin?, è possibile utilizzarne entrambi contemporaneamente.

Quando sceglieresti l'una contro l'altra? In quali circostanze sceglieresti di usarli entrambi insieme?

Answer 1

Sto valutando queste opzioni e qui è la conclusione che sono venuto a.

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 addon si arresta in modo anomalo, non verrà disattivata l'applicazione. Fornisce inoltre un modo molto completo di disaccoppiare gli addons da qualsiasi cosa, a parte il contratto che gli dai. In effetti, puoi eseguire la versionizzazione degli adattatori del contratto per garantire la retrocompatibilità con i vecchi componenti aggiuntivi durante l'aggiornamento dell'app principale. Mentre questo suona alla grande, viene fornito con un prezzo pesante che devi pagare per attraversare i domini. 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 ... (tracciare uno spazio vuoto su questo). Il grado di isolamento che MAF ha non è presente nel MEF. Sono due quadri diversi per due cose diverse.

Answer 2

Quello che Danielg ha detto è buono. Vorrei aggiungere:

Se si guarda il video su System.Addins, sono chiaramente parlando di progetti molto grandi. Parla di una squadra gestendo l'applicazione host, un'altra squadra gestendo ogni AddIn e una terza squadra gestendo 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 tu hai l'idea). Se hai guardato quei video, puoi dire che la quantità di lavoro da utilizzare su 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 puoi rompere nessuno di quei contratti add-in sotto pena di morte.

D'altra parte, MEF sembra condividere più somiglianze con lo schema di add-in di SharpDevelop, l'architettura di plugin Eclipse o Mono.Addins. È molto più facile da capire rispetto a System.Addins e credo che sia molto più flessibile. Le cose che si perdono sono che non si ottiene l'isolamento di AppDomain o contratti di versioning forti prontamente con MEF. I punti di forza di MEF sono la possibilità di strutturare l'intera applicazione come una composizione di parti, in modo da poter spedire il prodotto in diverse configurazioni per diversi clienti e, se il cliente acquista una nuova funzione, è sufficiente rilasciare la parte per tale funzionalità nella propria directory di installazione e l'applicazione lo vede e lo esegue. Facilita anche i test. È possibile creare un'istanza dell'oggetto che si desidera testare e alimentarlo con oggetti fittizi per tutte le sue dipendenze, ma quando viene eseguito come un'applicazione composta, il processo di composizione aggancia automaticamente tutti gli oggetti reali.

Il punto più importante che vorrei menzionare è che, anche se è System.Addins nel quadro già, non vedo un sacco di prove di chi lo utilizza, ma MEF è appena seduto lì sul CodePlex presumibilmente essere incluso in .NET 4, e le persone stanno già iniziando a creare molte applicazioni con esso (me incluso). Penso che ti dica qualcosa sui due quadri.

Answer 3

Dal mio punto di vista le due tecnologie si rivolgono in realtà a casi d'uso molto diversi.

Il MEF è tipicamente il migliore in uno scenario di immissione di dipendenza pura in cui la persona o il gruppo che fornisce la soluzione integrata finale sta assemblando tutto e garantisce l'integrità generale, ma ha bisogno di implementazioni diverse delle funzionalità chiave.

MAF è per uno scenario in cui qualcuno/gruppo sta sviluppando una piattaforma o un host e altri gruppi aggiungeranno funzionalità dopo il fatto e in un modo non sotto il controllo del gruppo host. In questo scenario c'è bisogno di meccanismi più elaborati per "proteggere" l'host dai componenti aggiuntivi non autorizzati (o per proteggere i componenti aggiuntivi l'uno dall'altro).

Una terza tecnologia simile nel modello è l'intero schema di ProviderBase. Ciò consente anche di sostituire una capacità, ma il suo obiettivo è in realtà lo scenario in cui l'host/app ha assolutamente bisogno di una capacità e la necessità è in realtà di specificare diverse implementazioni tramite la configurazione.

Answer 4

Ho appena trovato questo lungo articolo che discute sia di MAF che di MEF. http://emcpadden.wordpress.com/2008/12/07/managed-extensibility-framework-and-others/

Oltre ai punti avanzate dalle altre risposte, sembra come se una delle differenze principali tra MEF e MAF è che Extensibility Framework gestito consentirebbe una parte componibili dipendere da un altro. Ad esempio, consentirebbe a un plug-in di dipendere da un altro plug-in.

Anche il Managed Extensibility Framework non fa distinzioni tra l'host e il componente aggiuntivo, come fa System.AddIn. Per quanto riguarda il MEF, sono solo parti componibili.

Answer 5

Avendo sviluppato e spedito un'applicazione MAF. Le mie opinioni su MAF sono un po 'stanche.

MAF è un sistema "disaccoppiato" o "allentato" nel peggiore dei casi. MEF è il sistema "accoppiato" o "allentato-coppia" al meglio.

benefici MAF che abbiamo realizzato utilizzando MAF sono:

1. Installazione di nuovo o l'aggiornamento di componenti esistenti, mentre l'applicazione è in esecuzione. Il componente aggiuntivo potrebbe essere aggiornato mentre l'applicazione era in esecuzione e gli aggiornamenti vengono visualizzati all'utente senza problemi. Devi avere AppDomains per questo.

2. Licenza basata sui componenti acquistati. Potremmo controllare quali AddIn sono stati caricati dal ruolo e dalle autorizzazioni dell'utente e se l'AddIn è stato concesso in licenza per l'uso.

3. Sviluppo rapido (time-to-market più rapido). Lo sviluppo di AddIn si adatta perfettamente con il metodo Agile, il team di sviluppo ha sviluppato un AddIn alla volta senza dover sviluppare anche il pezzo di integrazione con il resto dell'applicazione.

4. QA migliorato (solo QA un componente alla volta). Il QA potrebbe quindi testare ed emettere difetti per un singolo bit di funzionalità. I test case erano più facili da sviluppare e implementare.

5. Distribuzione (aggiungere componenti man mano che vengono sviluppati e rilasciati e "funzionano"). La distribuzione è solo una questione di creare un AddIn e installare il file. Non sono necessarie altre considerazioni!

6. I nuovi componenti hanno funzionato con componenti vecchi. AddIn che sono stati sviluppati presto hanno continuato a funzionare.Nuove AddIns inseriscono nel applicazione senza soluzione di continuità

Answer 6

A mio parere, il modo migliore per scoprire le differenze è qualche hands-on di codice. Ho trovato due MSDN procedure dettagliate, sia con un esempio di calcolatrice in modo da poter facilmente confrontare le loro implementazioni:

MEF:Simple calculator example using MEF parts
(M anaged E xtensibility F QUADRO)

• Mostra come costruire un semplice calcolatore usando la tecnologia MEF. Non mostra come caricare le DLL esterne. (Ma si può semplicemente modificare l'esempio utilizzando catalog.Catalogs.Add(new DirectoryCatalog("Plugins", "*.dll")); invece di utilizzare catalog.Catalogs.Add(new AssemblyCatalog(typeof(Program).Assembly)); ed estrarre il codice calcolatrice e contratto per i progetti DLL separati.)

• MEF non lo fa necessità di avere una specifica struttura di directory, è semplice e intuitivo da usare, anche per piccoli progetti. Lo standard funziona con gli attributi, per dichiarare ciò che viene esportato, che è di facile lettura e comprensione. Esempio: [Export(typeof(IOperation))] [ExportMetadata("Symbol", '+')] class Add: IOperation { public int Operate(int left, int right) { return left + right; } }

• MEF non si occupa automaticamente delle versioni

MAF:Simple calculator with V1 and V2 version MAF plugins
(M anaged Un DDIN F QUADRO)

• Mostra come compilare la calcolatrice utilizzando un plug-in V1 e quindi come passare a un plug-in V2 mantenendo la retrocompatibilità (nota: è possibile trovare la versione V2 del plug-in here, il collegamento nel Articolo originale è rotto)
• MAF impone una specifica struttura di directory , e ha bisogno di un sacco di codice boilerplate per farlo funzionare, quindi io non lo consiglio per i piccoli progetti. Esempio:

  Pipeline 
      AddIns 
      CalcV1 
      CalcV2 
      AddInSideAdapters 
      AddInViews 
      Contracts 
      HostSideAdapters 
  

Sia MEF e MAF sono inclusi nel .NET Framework 4.x. Se si confrontano i due esempi si noterà che i plugin MAF hanno una complessità molto maggiore rispetto al framework MEF - quindi è necessario pensare attentamente quando utilizzare quale di questi framework.

Answer 7

MAF e MEF entrambi possono utilizzare AppDomains ed entrambi possono caricare/scaricare dll in runtime. Tuttavia, le differenze che ho riscontrato sono: gli AddIn MAF sono disaccoppiati, i componenti MEF sono accoppiati; MAF "Attiva" (nuova istanza) mentre MEF crea istanze per impostazione predefinita.

Con MEF è possibile utilizzare Generics per rendere 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.