Estoy tratando de entender mi Managed Extensibility Framework (MEF) por el momento y profundizar un poco. Tengo un fondo de Eclipse así que en mi cerebro que tengo actualmente la ecuación:¿Es MEF OSGi para .NET?
MEF =~ OSGi for .NET
Sobre la base de lo que he oído hasta ahora. ¿Estoy en las líneas correctas?
Scott Hanselman ayudó a resaltar las características específicas de MEF en su podcast 148 con Glenn Block.
En comparación con OSGi, MEF se basa en "Inversión de control" y OSGi no lo es: (OSGi) descubrirá nuevo paquete a través de un mecanismo diferente basado en una capa de ciclo de vida.
MEF se centra en la extensibilidad de la aplicación. Utiliza DI como una estrategia para componer las diferentes extensiones, , sin embargo, no es en sí un contenedor DI genérico.
Desde el último punto puede ser confuso, el transcripts del podcast puede ayudar:
La forma en que, básicamente, posición que, sin embargo, la diferencia entre los dos, es que los contenedores IoC son realmente acerca de la gestión a conocido conjunto de cosas en diferentes entornos, como quiero un registrador en el entorno de mi disco, quiero un registrador simulado en mi entorno de prueba.
Así MEF es realmente acerca de la gestión de un desconocida conjunto de las cosas y lo que se reduce a es que en un contenedor IoC que tienden a hacer bien una basada en la convención o un registro, mecanismo de registro específico, a decir aquí es lo logger significa, esto es lo que esto significa, esto es lo que eso significa.
MEF usa el código y un mecanismo de descubrimiento y anotaciones en el código, que son atributos , donde lo que aparece en el sistema, eso es lo que hay allí.
Así que de nuevo, llevándolo a un nivel más alto, se trata de utilizar el MEF para gestionar realmente un conjunto de desconocidos cosas, se utiliza IoC contenedores para gestionar un conjunto de conocidos cosas.
Conclusión: (uno de) la principal diferencia es el principio descubrimiento (COI vs. ciclo de vida)
creo que el podcast fue ligeramente mal transcritas: "contenedores IoC son realmente acerca de la gestión de conjunto desconocido de cosas" debe ser "contenedores IoC son realmente acerca de la gestión de un conjunto conocido de cosas" –
@ Daniel Gracias. Fijo. – VonC
Menciona que MEF se basa en "Inversión de control". http://ayende.com/Blog/archive/2008/09/25/the-managed-extensibility-framework.aspx dice que el Framework de Extensibilidad Administrada no es un contenedor IoC. – bhadra
en cuenta que OSGi está diseñado para que un contenedor IoC se puede proporcionar en la parte superior de la misma como un módulo , en realidad, hay varios contenedores IoC para OSGi disponibles, así como otros mecanismos: DS, iPOJO, Blueprint e indudablemente otros.
Encontré un artículo interesante sobre el uso de OSGi para abordar las deficiencias en un enfoque de COI puro: http://www.theserverside.com/feature/OSGi-is-the-framework-for-all-modular-applications. – Jonathan
Acabo de tropezar con esto, pero Prism parece ser lo más parecido a OSGi en .NET que he visto. Mira su sección Modular Application Development en los documentos.
Solo mire su ejemplo de las dependencias de los módulos (¡casi equivalentes a los paquetes!):
<modules>
<module assemblyFile="Modules/ModuleD.dll" moduleType="ModuleD.ModuleD, ModuleD" moduleName="ModuleD">
<dependencies>
<dependency moduleName="ModuleB"/>
</dependencies>
</module>
Parece que más de Microsoft, los patrones & equipo Prácticas sirve como una especie de OSGi Alliance equivalente.
Has aceptado la respuesta menos representativa. Sin saber nada sobre MEF, no puedo comparar los dos, pero puedo confirmar con firmeza que IoC NO es un problema para OSGi, por lo que no puede usarse como una característica distintiva. Por cierto, ¿qué terminaste eligiendo para tu proyecto? – drozzy