¿A dónde va el marco de extensibilidad gestionada para .NET?
https://stackoverflow.com/questions/42251
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
¿Alguien ha trabajado mucho con el Managed Extensibility Framework (MEF) de Microsoft?Suena como si intentara ser todo para todas las personas: ¡es un administrador de complementos!¡Es como escribir pato!Me pregunto si alguien tiene alguna experiencia con esto, positiva o negativa.
Actualmente estamos planeando utilizar una implementación genérica de IoC como MvcContrib para nuestro próximo gran proyecto.¿Deberíamos incluir a MEF en la mezcla?
Solución
No pretendemos que MEF sea un COI polivalente.La mejor manera de pensar en los aspectos de IoC de MEF es un detalle de implementación.Usamos IoC como patrón porque es una excelente manera de abordar los problemas que buscamos resolver.
MEF se centra en la extensibilidad.Cuando piense en MEF, considérelo como una inversión para hacer avanzar nuestra plataforma.Nuestros productos futuros y la plataforma aprovecharán MEF como mecanismo estándar para agregar extensibilidad.Los productos y marcos de terceros también podrán aprovechar este mismo mecanismo.El "usuario" promedio de MEF creará componentes que MEF consumirá y no consumirá MEF directamente dentro de sus aplicaciones.
Imagínese que cuando quiera ampliar nuestra plataforma en el futuro, coloca un dll en la carpeta bin y listo.La aplicación habilitada para MEF se ilumina con la nueva extensión.Esa es la visión del MEF.
Otros consejos
Esta publicación hace referencia a la Vista previa 2 del marco de extensibilidad administrada.
Entonces, revisé MEF y escribí un rápido "Hola mundo", que se presenta a continuación.Debo decir que fue totalmente fácil sumergirse y comprender.El sistema de catálogo es fantástico y hace que ampliar MEF sea muy sencillo.Es trivial apuntarlo a un directorio de ensamblados de complementos y dejar que se encargue del resto.La herencia de MEF, ala Prism, ciertamente se muestra, pero creo que sería extraño si no fuera así, dado que ambos marcos tienen que ver con la composición.
Creo que lo que más me llama la atención es la "magia" de _container.Compose().Si observa la clase HelloMEF, verá que el campo de saludos nunca se inicializa con ningún código, lo cual resulta curioso.Creo que prefiero la forma en que funcionan los contenedores de IoC, donde le pides explícitamente al contenedor que cree un objeto para ti.Me pregunto si algún tipo de inicializador genérico "Nada" o "Vacío" podría ser adecuado.es decir.
private IGreetings greetings = CompositionServices.Empty<IGreetings>();
Eso al menos llena el objeto con "algo" hasta el momento en que el código de composición del contenedor se ejecuta para llenarlo con un "algo" real.No lo sé, huele un poco a las palabras clave Vacío o Nada de Visual Basic, lo cual siempre no me gustó.Si alguien más tiene alguna idea sobre esto, me gustaría escucharla.Quizás sea algo que necesito superar.Está marcado con un atributo grande y gordo [Importar], por lo que no es como si fuera un completo misterio ni nada por el estilo.
Controlar la vida útil del objeto no es obvio, pero todo es un singleton de forma predeterminada a menos que agregue un atributo [CompositionOptions] a la clase exportada.Eso le permite especificar Factory o Singleton.Sería bueno ver que Pooled se agregue a esta lista en algún momento.
No tengo muy claro cómo funcionan las funciones de escritura del pato.Parece más una inyección de metadatos al crear un objeto que una escritura patosa.Y parece que solo puedes agregar un pato adicional.Pero como dije, todavía no tengo muy claro cómo funcionan estas funciones.Ojalá pueda volver y completar esto más tarde.
Creo que sería una buena idea realizar una instantánea de las DLL cargadas por DirectoryPartCatalog.En este momento, las DLL están bloqueadas una vez que MEF las controla.Esto también le permitiría agregar un observador de directorio y detectar complementos actualizados.Eso sería muy amable...
Finalmente, me preocupa qué tan confiables son las DLL complementarias y cómo se comportará MEF, o si lo hará, en un entorno de confianza parcial.Sospecho que las aplicaciones que utilizan MEF requerirán plena confianza.También podría ser prudente cargar los complementos en su propio dominio de aplicación.Sé que huele un poco a System.AddIn, pero permitiría una separación muy clara entre complementos de usuario y complementos del sistema.
Bien, basta de tonterías.Aquí está Hola mundo en MEF y C#.¡Disfrutar!
using System;
using System.ComponentModel.Composition;
using System.Reflection;
namespace HelloMEF
{
public interface IGreetings
{
void Hello();
}
[Export(typeof(IGreetings))]
public class Greetings : IGreetings
{
public void Hello()
{
Console.WriteLine("Hello world!");
}
}
class HelloMEF : IDisposable
{
private readonly CompositionContainer _container;
[Import(typeof(IGreetings))]
private IGreetings greetings = null;
public HelloMEF()
{
var catalog = new AggregateCatalog();
catalog.Catalogs.Add(new AssemblyCatalog(Assembly.GetExecutingAssembly()));
_container = new CompositionContainer(catalog);
var batch = new CompositionBatch();
batch.AddPart(this);
container.Compose(batch);
}
public void Run()
{
greetings.Hello();
}
public void Dispose()
{
_container.Dispose();
}
static void Main()
{
using (var helloMef = new HelloMEF())
helloMef.Run();
}
}
}
En cuanto a la pregunta de Andy sobre la seguridad de las extensiones que carga MEF (lo siento, todavía no tengo suficientes puntos :)), el lugar para abordar esto es en un Catálogo.Los catálogos MEF son completamente conectables, por lo que puede escribir un catálogo personalizado que valide las claves de ensamblaje, etc. antes de cargarlos.Incluso podrías usar CAS si así lo deseas.Estamos considerando la posibilidad de proporcionar enlaces que le permitan hacer esto sin tener que escribir un catálogo.Sin embargo, la fuente de los catálogos actuales está disponible gratuitamente.Sospecho que lo mínimo es que alguien (tal vez de nuestro equipo) implemente uno y lo incluya en un proyecto de extensión/contribución en CodePlex.
La escritura de pato no se enviará en V1, aunque está en la versión actual.En un lanzamiento futuro lo reemplazaremos con un mecanismo adaptador enchufable donde se podría enganchar un mecanismo de escritura tipo pato.La razón por la que analizamos la tipificación de patos es para abordar escenarios de control de versiones.Con Duck Typing puede eliminar las referencias compartidas entre exportadores e importadores, permitiendo así que varias versiones de un contrato convivan una al lado de la otra.
Andy, creo que Glenn Block responde a muchas preguntas (naturales) como estas en este hilo del foro MSDN MEF:
Comparación de CompositionContainer con contenedores IoC tradicionales .
Hasta cierto punto, la respuesta anterior de Artem es correcta en relación con la intención principal detrás de MEF, que es la extensibilidad y no la composición.Si lo que más le interesa es la composición, utilice uno de los otros sospechosos habituales de IoC.Si, por otro lado, lo que más le preocupa es la extensibilidad, entonces la introducción de catálogos, piezas, etiquetado de metadatos, tipeo flexible y carga retrasada ofrecen algunas posibilidades interesantes.Además, Krzysztof Cwalina dispara aquí para explicar cómo MEF y System.Addins se relacionan entre sí.
Ayende también tiene un artículo bastante bueno aquí: http://ayende.com/Blog/archive/2008/09/25/the-managed-extensibility-framework.aspx
No es una inyección de contenedor de control.Es un marco de soporte de complementos.
Yo diría que, dado que va a colgar del espacio de nombres 'Sistema' en .NET 4.0 Framework, no puedes equivocarte demasiado.Será interesante ver cómo evoluciona el MEF y qué influencia tiene Hamilton Verissimo (Castle) en la dirección del MEF.
Si grazna como un pato, podría ser parte de la actual bandada de contenedores de COI...
Discusión más detallada sobre esto en esta publicación y los comentarios.
http://mikehadlow.blogspot.com/2008/09/managed-extensibility-framework-why.html
