¿Qué falta en MEF para estar a la par con los contenedores de IoC?

Question

MEF isnot anIoCcontainer. Pero parece que es casi un contenedor IoC. Parece que puedo hacer que MEF se comporte fácilmente como un contenedor de IoC (ver el ejemplo a continuación) y no falta mucho para hacer de MEF un contenedor IoC completo.

¿Cuáles son las características reales que faltan en MEF que StrucureMap, Unity, etc. tienen que ponerse a la par?

¿Pensarías que this feaure request tiene sentido?

using System; 
using System.Collections.Generic; 
using System.ComponentModel.Composition; 
using System.ComponentModel.Composition.Hosting; 
using System.ComponentModel.Composition.Primitives; 
using System.Linq; 
... 
private CompositionContainer container; 
public void Configure() 
{ 
    container = CompositionHost.Initialize( 
     new AggregateCatalog(
      AssemblySource.Instance.Select(
       x => new AssemblyCatalog(x)).OfType<ComposablePartCatalog>()));  
     var batch = new CompositionBatch();   
     batch.AddExportedValue<IWindowManager>(new WindowManager()); 
     batch.AddExportedValue<IEventAggregator>(new EventAggregator()); 
     batch.AddExportedValue(container);   
     container.Compose(batch); 
} 

Answer 1

Según lo discutido, MEF no se construyó para ser un contenedor de IoC. Sin embargo, tiene muchas similitudes. Si la funcionalidad que proporciona MEF es suficiente para sus necesidades de contenedor de IoC, puede continuar y utilizarla como un contenedor de IoC.

Si bien MEF probablemente nunca se adapte a las necesidades de contenedores IoC de todos, en la próxima versión estamos haciendo cambios que creo que valdrán la pena utilizar como contenedores IoC para más personas. Éstos son algunos de ellos:

• Opcionalmente deshabilitar el rechazo más fácil para el diagnóstico de errores en un sistema en el que no desea nada para ser rechazada
• apoyo modelo de la Convención que le permite registrar los tipos a ser exportados e importados en vez de agregar atributos de exportación e importación en los tipos mismos.
• Abra el soporte genérico, por lo que puede exportar un genérico abierto e importar una versión cerrada.
• Mejor soporte para contenedores delimitados/jerárquicos, que pueden ayudar con la administración de por vida.

Thomas menciona la intercepción como una característica importante. Actualmente no tenemos planes para incluir soporte para esto de manera inmediata. MefContrib tiene algo de apoyo para esto en la forma de un Catalogo de Interceptación, creo.

Answer 2

No estoy al tanto de las características de los lates MEF pero lo que puedo decir es que el MEF es un marco que responde a las preocupaciones de extensibilidad para aplicaciones. La atención se centra en habilitar escenarios de complementos para el software estándar. Comparte tantos rasgos con Contenedores IoC "adecuados" que puede convertirse en un contenedor IoC completo en el futuro.

Mef fue construido para un propósito diferente al de un contenedor IoC. Su objetivo es proporcionar un marco común para habilitar la funcionalidad de complemento para aplicaciones estándar. Desde la perspectiva de una aplicación estándar, un complemento es esencialmente , un componente desconocido.

Cuando utilizamos un Contenedor de IoC como herramienta para componer una aplicación, conocemos los componentes que componen la aplicación.

Los contenedores IoC apuntan a una composición desacoplada de servicios que es buena, pero el desarrollador debe conocer los componentes que desea componer en el momento en que se configura el conainer cuando MEF apunta a la capacidad de descubrimiento de los componentes. Lo único que debes saber es sobre una abstracción que quieras usar.

MEF comparte tantas similitudes con los Contenedores de IoC que a veces es difícil decir cómo deberíamos considerarlo.

creo que la disaventage principal del MEF es:

• mala gerencia vida útil en comparación con el COI
• falta de intercepción

Cuáles son los puntos principales cuando se habla de contenedores COI.

Answer 3

¿Qué le falta a MEF para estar a la par con los contenedores de IoC?

Una forma fácil de diagnosticar problemas en una composición.

Por ejemplo, si tiene una cadena de dependencias A -> B -> C -> D, y D no se encuentra, entonces de acuerdo con el principio de stable composition MEF simplemente marcar A, B y C como no disponible e intentará para hacer la composición sin esas partes. Su mensaje de error se va a quejar de A, no D.

Para diagnosticar el problema, tendrá que volcar los diagnósticos de composición de alguna manera (por ejemplo, con mefx) y seguir cuidadosamente la ruta de dependencia hacia abajo hasta encontrar el problema real . Lo cual es un dolor pero funciona, hasta que introduces dependencias cíclicas ...

Un contenedor de IoC regular no tiene este problema. Simplemente te dirá "hey, has registrado C para usar en la composición, pero parece que no puedo encontrar su dependencia D".

Vea también mi blog post sobre este tema.