2011-02-10 22 views
8

Correggimi se ho torto, ma MEF è utile solo per gestire un insieme di cose sconosciute (plug-in) che possono essere individuate automaticamente e cablate automaticamente. Per un progetto futuro avremo bisogno di un vero contenitore IoC per configurare in modo esplicito le parti conosciute dell'applicazione (che MEF non è bravo a) ma in aggiunta dobbiamo anche supportare i plugin autodiscover (preferibilmente POCO senza attributi, se possibile). Un container IoC può supportarlo facilmente/per impostazione predefinita? In caso affermativo, puoi dare un suggerimento rapido su come eseguire l'operazione in Unity e StructureMap? Questi sono i due che attualmente preferiamo. Vorremmo davvero evitare una dipendenza da un contenitore IoC e da ME.Usa contenitore IoC per architettura plugin

+0

Cosa c'è di sbagliato nell'usare MEF per i plugin? È progettato esattamente per quel caso d'uso e la sua parte del framework .Net. – jeroenh

+0

Dai un'occhiata a Spring.Net. –

+1

Hai detto che vuoi evitare di avere un contenitore IoC e MEF, quindi non lo invierò come risposta. Ma [Autofac] (http://nblumhardt.com/2010/04/introducing-autofac-2-1-rtw/) si integra abbastanza bene con MEF. –

risposta

8

Penso che sia importante notare che mentre MEF non è un contenitore IoC in senso convenzionale, sta eseguendo l'inversione del controllo. In realtà, non sarei d'accordo e direi che MEF è un contenitore IoC molto simile a qualsiasi altro. La vera differenza tra say Unity e MEF, è che MEF di default supporta la composizione su una risoluzione di tipo esplicita e digita discovery over configuration. Ma, come abbiamo visto con il progetto MEFContrib, è possibile che il comportamento di MEF sia più simile a un contenitore IoC tradizionale. MEF fornisce una linea di base eccellente per il comportamento dei componenti modulari, prendendo molto del duro innesto e il modo in cui è progettato, ti permette di aggiungere più funzionalità esso. Diciamo per esempio che la base di codice esistente è stata costruita attorno a un altro contenitore o localizzatore di servizi IoC, è possibile collegare uno ExportProvider per fare ciò, è possibile collegare un provider a un servizio di localizzazione come il progetto Common Service Locator e quindi collegare un compatibile Implementazione CSL e MEF che compone parti componenti utilizzando tipi derivati ​​dall'altro contenitore IoC. MEF esegue anche l'iniezione di dipendenza per te.

Se si vuole evitare di avere una dipendenza da uno specifico contenitore IoC o MEF stesso, si può sempre usare qualcosa come il Local Service Locator che è un'astrazione sulle operazioni di contenitore comune. In questo modo se hai bisogno/vuoi cambiare il modo in cui tutto è scandagliato insieme, è relativamente indolore. Esistono implementazioni CSL compatibili per la maggior parte dei contenitori IoC e MEF.

Spero che questo aiuti.

+0

Il contributo di MEF consentirebbe alle parti di essere POCO senza attributi? – bitbonk

+2

Il modello Attribuito è solo il modello di programmazione predefinito per MEF. MEFContrib ha un 'ConventionCatalog', che combinato con' PartRegistry' ti permette di registrare i tipi più come contenitori Unity/Autofac/Windsor ecc. –

Problemi correlati