Sto solo provando a girare la testa allo Managed Extensibility Framework (MEF) al momento e a scavare un po '. Ho un fondo Eclipse così nel mio cervello Al momento ho l'equazione:MEF OSGi for .NET?
MEF =~ OSGi for .NET
In base a quello che ho sentito finora. Sono sulla buona strada?
Scott Hanselman ha contribuito a mettere in evidenza le specifiche di MEF nel suo podcast 148 con Glenn Block.
Rispetto a OSGi, MEF è basato su "Inversion of Control" e OSGi non lo è: esso (OSGi) scoprirà il nuovo bundle attraverso un meccanismo diverso basato su un Life Cycle Layer.
MEF si concentra sull'estensibilità dell'applicazione. Utilizza la DI come strategia per comporre le diverse estensioni, ma non è di per sé un contenitore DI generico.
Poiché l'ultimo punto può confondere il transcripts del podcast può aiutare:
Il modo fondamentalmente posiziono però, la differenza tra i due, è che i contenitori IoC sono veramente sulla gestione a noto come insieme di cose in ambienti diversi, come voglio un logger nel mio ambiente del disco, voglio un logger finto nel mio ambiente di test.
Quindi MEF è realmente circa la gestione di un sconosciuta insieme di cose e che cosa si riduce a è che in un IoC Container tendo a fare sia una convenzione-based o una registrazione, meccanismo di registrazione specifici, per dire ecco cosa logger significa, ecco cosa significa, ecco cosa significa.
MEF utilizza il codice e un meccanismo di scoperta e annotazioni sul codice, che sono attributi , dove qualsiasi cosa si presenta nel sistema, questo è ciò che è lì.
Quindi, di nuovo, portandolo ad un livello più alto, si tratta di utilizzare MEF per gestire davvero un insieme di sconosciuti cose, si utilizza IoC Container per gestire una serie di noti cose.
Conclusione: (uno) la differenza principale è il principio scoperta (IOC vs. ciclo di vita)
Penso che il podcast sia stato leggermente mistificato: "I contenitori IoC si occupano veramente di gestire un insieme di cose UNKNOWN" dovrebbe essere "I contenitori IoC servono davvero a gestire un insieme di cose CONOSCIUTO" –
@Daniel Grazie. Fisso. – VonC
Hai detto che MEF è basato su "Inversion of Control". http://ayende.com/Blog/archive/2008/09/25/the-managed-extensibility-framework.aspx afferma che Managed Extensibility Framework non è un contenitore IoC. – bhadra
noti che OSGi è progettato in modo che un contenitore CIO può essere fornito su di esso come modulo , in realtà, ci sono più contenitori IoC per OSGi disponibili così come altri meccanismi: DS, iPOJO, Blueprint e senza dubbio altri.
Trovato un interessante articolo sull'utilizzo di OSGi per affrontare le carenze in un approccio di puro IOC: http://www.theserverside.com/feature/OSGi-is-the-quadro-per-tutte-modulari-applicazioni. – Jonathan
Appena inciampato su questo, ma Prism sembra essere la cosa più vicina a OSGi in. NET che ho visto! Guarda la loro sezione Modular Application Development nei documenti.
Basta dare un'occhiata al loro esempio delle dipendenze del modulo (quasi equivalenti ai pacchetti!):
<modules>
<module assemblyFile="Modules/ModuleD.dll" moduleType="ModuleD.ModuleD, ModuleD" moduleName="ModuleD">
<dependencies>
<dependency moduleName="ModuleB"/>
</dependencies>
</module>
Sembra che oltre a Microsoft, i modelli & Practices squadra serve come una sorta-di OSGi Alliance equivalente.
Hai accettato la risposta più non rappresentativa. Non sapendo nulla di MEF non posso confrontare i due, ma posso confermare con fermezza che IoC NON è affatto un problema per OSGi, quindi come tale non può essere usato come caratteristica distintiva. A proposito, che cosa hai scelto per il tuo progetto? – drozzy