Scelta tra MEF e MAF (System.AddIn)

https://stackoverflow.com/questions/835182

08-07-2019
|

Domanda

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?

Soluzione

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 arresta in modo anomalo, 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, ha 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.

Altri suggerimenti

Ciò che Danielg ha detto è buono. Vorrei aggiungere:

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 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 preconfezionati con MEF. I punti di forza di MEF sono che puoi strutturare l'intera tua applicazione come una composizione di parti, in modo da poter spedire il tuo prodotto in diverse configurazioni per clienti diversi e se il cliente acquista una nuova funzionalità, devi semplicemente rilasciare la parte per quella funzione nella directory di installazione e l'applicazione lo vede e lo esegue. Inoltre facilita i test. È possibile creare un'istanza dell'oggetto che si desidera testare e alimentare 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 è già nel framework, non vedo molte prove di persone che lo usano, ma MEF è semplicemente lì seduto su CodePlex presumibilmente per essere incluso in .NET 4 e le persone stanno già iniziando a creare molte applicazioni (incluso me stesso). Penso che questo ti dica qualcosa sui due framework.

Dopo aver sviluppato e spedito un'applicazione MAF. Le mie opinioni su MAF sono in qualche modo logore.

MAF è un "disaccoppiato" sistema o "liberamente accoppiati" sistema nel peggiore dei casi. MEF è "accoppiato" sistema o "vagamente accoppiamento" nel migliore dei casi.

I vantaggi di MAF che abbiamo realizzato utilizzando MAF sono:

Installazione di componenti nuovi o aggiornati 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 sono stati più facili da sviluppare e implementare.
Implementazione (aggiungi componenti man mano che vengono sviluppati e rilasciati e funzionano & # 8221; funzionano solo & # 8221;). 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 componenti vecchi. AddIn che sono stati sviluppati all'inizio hanno continuato a funzionare. I nuovi componenti aggiuntivi si adattano perfettamente all'applicazione

A mio avviso, 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 funzionalità 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 gli uni dagli altri).

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-estensibilità-quadro-e-altri /

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.

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

Secondo me, il modo migliore per scoprire le differenze è un codice pratico. Ho trovato due procedure dettagliate MSDN, entrambe con un esempio di calcolatrice in modo da poter confrontare facilmente le loro implementazioni:

MEF: Semplice esempio di calcolatrice usando parti MEF
( M anaged E estensibilità F ramework)

Mostra come creare un semplice calcolatore utilizzando la tecnologia MEF. Non mostra come caricare dll esterne. (Ma puoi semplicemente modificare l'esempio usando catalog.Catalogs.Add (nuovo DirectoryCatalog (" Plugin " ;, " *. dll ")); invece di utilizzare catalog.Catalogs.Add (nuovo AssemblyCatalog (typeof (Program) .Assembly)); ed estrae il file codice calcolatrice e contratto per separare progetti DLL.)
MEF non ha bisogno di avere una struttura di directory specifica, è semplice e diretto da usare, anche per piccoli progetti. funziona con gli attributi, per dichiarare ciò che viene esportato, che è facile da leggere e comprendere. Esempio: [Export (typeof (IOperation))] [ExportMetadata (" Symbol " ;, '+')] class Add: IOperation { public int Operate (int left, int right) { ritorna a sinistra + a destra; } }
MEF non si occupa automaticamente del controllo delle versioni

MAF: Calcolatrice semplice con versione V1 e V2 plugin MAF
( M anaged A ddin F ramework)

Mostra come costruire la calcolatrice utilizzando un plug-in V1 e quindi come passare a un plug-in V2 mantenendo la compatibilità con le versioni precedenti ( nota: puoi trovare la versione V2 del plug-in < a href = "https://msdn.microsoft.com/en-us/library/vstudio/bb384194(v=vs.100).aspx" rel = "noreferrer"> qui , il link nell'originale l'articolo è rotto)
MAF impone una specifica struttura di directory, e ha bisogno di molto codice boilerplate per farlo funzionare, quindi non lo consiglio per piccoli progetti. Esempio:
```
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.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow