Come stai usando il Managed Extensibility Framework?

Lavoro con MEF da circa 2 settimane. Ho iniziato a pensare a cosa serve MEF, cercando di scoprire come usare MEF e infine implementando un host con 3 moduli. I contratti si stanno dimostrando facili da comprendere e i moduli sono facilmente gestibili.

Sebbene MEF abbia un uso molto pratico, mi chiedo fino a che punto? Voglio dire, tutti riscriveranno le applicazioni esistenti per l'estensibilità?

Sì, sembra, ed è follemente impraticabile. Retoricamente parlando:

• in che modo MEF sta influenzando le attuali tendenze della programmazione?

• hai iniziato a cercare opportunità per utilizzare MEF?

• hai iniziato a pianificare un'importante riscrittura di un'app esistente che potrebbe beneficiare dell'estensibilità?

Detto questo, le mie domande sono:
come faccio a sapere quando dovrei pianificare un nuovo progetto con estensibilità?
come faccio a sapere se un progetto esistente deve essere riscritto per estensibilità?

Qualcuno sta usando MEF?

Qualcuno sta usando MEF?

Sto lavorando a un progetto Silverlight usando il modello MVVM. Abbiamo iniziato collegando semplicemente tutte le macchine virtuali insieme, se necessario, tramite interfacce e iniezione manuale di dipendenze (iniezione del costruttore o della proprietà a seconda delle necessità). Ha iniziato a diventare doloroso e abbiamo iniziato a utilizzare MEF come fondamentalmente un framework di iniezione di dipendenza per esportare determinati servizi che vengono utilizzati attraverso i modelli di vista e importarli nei modelli di vista che ne hanno bisogno. Funziona perfettamente e con pochissimo codice.

Sì, ci sono alcuni puristi là fuori che diranno che MEF non è inteso per l'iniezione di dipendenza e una vera e propria struttura di iniezione di dipendenza farà molto meglio. Tuttavia, MEF è integrato in .NET, il che è un grande vantaggio ed è stato sufficiente per soddisfare le nostre esigenze.

come faccio a sapere quando dovrei pianificare un nuovo progetto con estensibilità? come faccio a sapere se un progetto esistente deve essere riscritto per estensibilità?

IMO, dovresti sempre separare le preoccupazioni in modo appropriato e utilizzare le interfacce per consentire a diversi moduli di cambiare in modo indipendente. Se lo fai nel modo giusto, quando trovi una necessità di estensibilità, MEF dovrebbe essere facile da aggiungere. Ma non vorrei avviare un progetto senza requisiti di estensibilità e inserire MEF per ogni evenienza. Aspetterei che ce ne sia bisogno. Per i progetti esistenti, in caso di necessità, valuterei lo sforzo di ricablare il progetto per utilizzare MEF rispetto a soluzioni alternative anziché non fare nulla, e vedere quale vince.

L'errore che le persone commettono e penso che sia a causa della denominazione (Managed Extensibility Framework) è nel presupporre che MEF sia solo pratico per l'estensibilità. MEF affronta davvero tre cose chiave: estensibilità, scoperta e metadati. Gli ultimi due sono molto potenti anche per un'applicazione che non vedrà mai un singolo plug-in o estensione.

Questo è un articolo che ho scritto sul suo potere di scoperta come contenitore IOC: http://www.informit.com/articles/article.aspx?p=1635818

Uso MEF nella maggior parte delle applicazioni aziendali perché rende più veloce e semplice la creazione e la gestione di applicazioni modulari in Silverlight.

Attualmente sto usando MEF in alcuni progetti che incorporano il modello del repository.

Uno sta usando diversi tipi di repository durante il test unitario, l'altro progetto sta usando repository locali (direttamente su DB), remoti (WCF).

Entrambi i progetti possono modificare i tipi di repository tramite codice o configurazione ed è basato su metadati / tipi pigri di MEF.

Ad oggi, entrambi i progetti stanno andando incredibilmente bene.