Quando si organizza un progetto in cui dovrei inserire le interfacce del provider che sono utilizzate in MEF? Attualmente li ho solo nello stesso progetto di tutto il resto, ma sembra che potrebbe essere desiderabile per me estrarli in una dll separata in modo che fosse una dll molto piccola e sarebbe facilmente essere collegata da altri che tentano di scrivere estensioni. Che cosa è una buona pratica per questo?Dove dovrei inserire le interfacce per MEF?
Come con qualsiasi modello di plug-in/estensione, è necessario inserire i "contratti" (le interfacce che un autore di plug-in deve implementare) in un assieme separato dalla propria applicazione.
In questo modo è possibile rendere tale assembly disponibile per gli autori di plug-in senza dover fornire loro l'intera applicazione, utile se si tratta di un'app commerciale che è necessario acquistare separatamente.
MEF Preview 5 introduce la possibilità di esportare un'interfaccia (ad esempio aggiungere un attributo [Esporta] a un'interfaccia) in modo tale che qualsiasi implementatore di tale interfaccia venga automaticamente esportato. Ciò significa che gli autori di plug-in non hanno nemmeno bisogno di conoscere MEF: implementano semplicemente la tua interfaccia e sono automaticamente un'estensione MEF.
Inizialmente MEF implementava la digitazione anatra, il che significa che non sarebbe necessario un assemblaggio comune, ma a quanto pare questo si è rivelato troppo difficile.
li sto mettendo tutti in un assembly comune, insieme ad alcune utili classi di base astratte che possono essere utilizzate per aiutare a implementare le interfacce.
Interessante. Sono arrivato allo stesso modello da solo, indipendentemente.Solo la mia interfaccia non è un'interfaccia, è una classe astratta, perché ho finito per avere una funzione finale universale come codice reale. – JCCyC
Avevo anche la stessa domanda e volevo vedere un esempio in cui i contratti sono definiti in un progetto, più implementazioni sono definite in altri progetti e un separato progetti di consumo che utilizza il contratto e ha una cartella di estensione in cui le dll di implementazione possono essere semplicemente copiate ed è disponibile per l'applicazione consumer senza modifiche al codice. Così ho provato a scrivere un semplice tipo di applicazione Hello World e ho postato sul mio blog. Spero che tu possa trovare utile. Ho anche pubblicato il codice sorgente (in C#).
http://ppsinfo.blogspot.com/2009/11/managed-extensibility-framework-mef.html
in realtà non c'è nuova funzionalità di .NET 4.0 chiamato tipo di equivalenza che può raggiungere questo obiettivo. Con questa funzione è possibile disporre di due interfacce diverse in diversi gruppi di contratto che comunicano al CLR che sono uguali. Poiché è di basso livello, MEF può funzionare bene.
Qualche distinguo:
Si può leggere di più su di esso qui:.. http://msdn.microsoft.com/en-us/library/dd997297(VS.100).aspx La documentazione dirà che è per COM, ma è possibile utilizzarlo per il codice gestito pure
L'esportazione di un'interfaccia funziona bene se si importa solo uno di questi tipi.Il problema è se si desidera utilizzare due di quel tipo in diverse parti dell'applicazione, quindi è comunque necessario un nome di contratto, quindi è necessario esportare affermazione, giusto? –
Sì, se è necessario importare due diverse implementazioni della stessa interfaccia, è necessario distinguerle in qualche modo. l'implementazione è un modo semplice per farlo. Probabilmente potresti anche usare i metadati di esportazione, ma non ho giocato affatto con quello. –