Elegir entre MEF y MAF (Sistema.AddIn)

Lo que dijo Danielg es bueno. Yo añadiría:

Si ves los videos sobre el sistema.Addins, claramente están hablando de proyectos muy grandes. Habla de un equipo que administra la aplicación host, otro equipo que administra cada complemento, y un tercer equipo que administra el contrato y la canalización. Basado en eso, creo que el Sistema.Addins es claramente para aplicaciones más grandes. Estoy pensando en aplicaciones como sistemas ERP como SAP (quizás no tan grandes, pero obtienes idea). Si has visto esos videos se puede decir que la cantidad de trabajo para utilizar el sistema.Addins es muy grande. Funcionaría bien si tuviera muchas empresas que programan complementos de terceros para su sistema y no puede romper ninguno de esos contratos de complementos bajo pena de muerte.

Por otro lado, MEF parece compartir más similitudes con el esquema de complemento de SharpDevelop, la arquitectura de complemento Eclipse o Mono.Addins. Es mucho más fácil de entender que el Sistema.Addins and I believe it para ser mucho más flexible. Las cosas que pierdes son que no obtienes aislamiento de AppDomain o fuertes contratos de versiones listos para usar con MEF. Los puntos fuertes de MEF son que puede estructurar toda su aplicación como una composición de piezas, por lo que puede enviar su producto en diferentes configuraciones para diferentes clientes, y si el cliente compra una nueva función, simplemente suelta la pieza para esa función en su directorio de instalación y la aplicación la ve y la ejecuta. También facilita prueba. Puede crear instancias del objeto que desea probar y alimentarlo con objetos simulados para todas sus dependencias, pero cuando se ejecuta como una aplicación compuesta, el proceso de composición engancha automáticamente todos los objetos reales.

El punto más importante que me gustaría mencionar es que a pesar de Sistema.Addins ya está en el marco, no veo mucha evidencia de personas que lo usan, pero MEF está sentado allí en CodePlex supuestamente para ser incluido en. NET 4, y las personas ya están empezando a construir muchas aplicaciones con él (yo incluido). Creo que eso te dice algo sobre los dos marcos.

Habiendo desarrollado y enviado una aplicación MAF. Mis puntos de vista sobre MAF están un poco cansados.

MAF es un sistema "desacoplado" o en el peor de los casos un sistema "débilmente acoplado". MEF es un sistema" acoplado" o un sistema "vagamente acoplado" en el mejor de los casos.

Los beneficios de MAF que nos dimos cuenta al usar MAF son:

1. Instalación de componentes nuevos o actualización de componentes existentes mientras se ejecuta la aplicación. El AddIn se puede actualizar mientras la aplicación se está ejecutando y las actualizaciones aparecen al usuario sin problemas. Tienes que tener AppDomains para eso.

2. Licencias basadas en componentes adquiridos. Podríamos controlar qué AddIn fueron cargados por el rol y los permisos del usuario y si el AddIn tenía licencia para su uso.

3. Desarrollo rápido (tiempo de comercialización más rápido). El desarrollo de AddIn encaja perfectamente con la metodología Ágil, el equipo de desarrollo desarrolló un AddIn a la vez sin tener que desarrollar también la pieza de integración con el resto del aplicación.

4. QA mejorado (solo QA un componente a la vez). QA podría entonces probar y emitir defectos para un solo bit de funcionalidad. Los casos de prueba fueron más fáciles de desarrollar e implementar.

5. Implementación (agregue componentes a medida que se desarrollan y lanzan y "simplemente funcionan"). La implementación es solo una cuestión de hacer un AddIn e instalar el archivo. ¡No fueron necesarias otras consideraciones!

6. Nuevos componentes trabajaron con componentes antiguos. AddIn que se desarrollaron desde el principio siguieron funcionando. Los nuevos complementos encajan perfectamente en la Aplicación

En mi opinión, las dos tecnologías en realidad se dirigen a casos de uso muy diferentes.

MEF es típicamente mejor en un escenario de inyección de dependencia pura donde la persona o grupo que entrega la solución integrada final está ensamblando todo y dando fe de la integridad general, pero tiene la necesidad de tener diferentes implementaciones de capacidades clave.

MAF es para un escenario donde alguien / grupo está desarrollando una plataforma o host y otros grupos agregarán capacidades después del hecho y de una manera que no está bajo el control del grupo anfitrión. En este escenario, la necesidad es de mecanismos más elaborados para" proteger " el host de los complementos falsos (o para proteger los complementos entre sí).

Una tercera tecnología similar en el patrón es todo el esquema de la base de proveedores. Esto también permite reemplazar una capacidad, pero su objetivo es realmente el escenario donde el host/aplicación absolutamente necesita una capacidad y la necesidad es realmente especificar diferentes implementaciones a través de config.

Acabo de encontrar este largo artículo discutiendo tanto MAF como MEF. http://emcpadden.wordpress.com/2008/12/07/managed-extensibility-framework-and-others /

Además de los puntos hechos por las otras respuestas, suena como si una de las diferencias clave entre MEF y MAF es que el Marco de Extensibilidad Administrada permitiría que una parte componible dependiera de otra. Dejaría que un plug-in dependiera de otro plug-in, por ejemplo.

La Extensibilidad Administrada Framework tampoco hace distinciones entre el host y el complemento, como el Sistema.AddIn lo hace. En lo que respecta a MEF, son solo partes componibles.

En mi opinión, la mejor manera de descubrir las diferencias es un código práctico. Encontré dos tutoriales de MSDN, ambos con un ejemplo de calculadora para que pueda comparar fácilmente sus implementaciones:

MEF: Ejemplo de calculadora simple usando MEF parts
(Managed Extensibility Framework)

• Muestra cómo construir una calculadora simple usando la tecnología MEF. No muestra cómo cargar archivos DLL externos. (Pero puedes simplemente modifique el ejemplo usando catalog.Catalogs.Add(new DirectoryCatalog("Plugins", "*.dll")); en lugar de usar catalog.Catalogs.Add(new AssemblyCatalog(typeof(Program).Assembly)); y extraer el código de calculadora y contrato para separar proyectos DLL.)

• MEF no necesita tener una estructura de directorios específica, es simple y directo de usar, incluso para proyectos pequeños. funciona con atributos, para declarar lo que se exporta, lo cual es fácil de leer y entender. Ejemplo: [Export(typeof(IOperation))] [ExportMetadata("Symbol", '+')] class Add: IOperation { public int Operate(int left, int right) { return left + right; } }

• MEF no trata automáticamente con versionado

MAF: Calculadora simple con la versión V1 y V2 MAF plugins
(Managed Unddin Framework)

• Muestra cómo construir la calculadora usando un plugin V1 y luego cómo pasar a un plugin V2 manteniendo la compatibilidad hacia atrás (nota: puede encontrar la versión V2 del plugin aquí , el enlace en el artículo original está roto)
• MAF impone una estructura de directorios específica, y necesita mucho código repetitivo para que funcione, por lo que no lo recomiendo para proyectos pequeños. Ejemplo:

  Pipeline
    AddIns
      CalcV1
      CalcV2
    AddInSideAdapters
    AddInViews
    Contracts
    HostSideAdapters
  

Tanto MEF como MAF están incluidos en.NET Framework 4.x. Si compara los dos ejemplos, notará que los complementos MAF tienen mucha más complejidad en comparación con el marco MEF, por lo que debe pensar cuidadosamente cuándo usar cuál de esos marcos.

MAF y MEF pueden usar AppDomains y ambos pueden cargar/descargar dll en tiempo de ejecución. Sin embargo, las diferencias que he encontrado son: MAF AddIns están desacoplados, MEF componentes están sueltos acoplados; MAF "Activa" (nueva instancia), mientras que MEF hace instancias por defecto.

Con MEF puede usar Generics para hacer GenericHost para cualquier contrato. Esto significa que la gestión de carga/descarga y componentes de MEF puede estar en una biblioteca común y usarse genéricamente.