Elegir entre MEF y MAF (System.AddIn)

El marco de extensibilidad administrada (MEF) y el marco de complemento administrado (MAF, también conocido como System.AddIn) parecen realizar tareas muy similares. De acuerdo con esta pregunta de desbordamiento de pila, ¿MEF es un reemplazo para System.Addin? , incluso puedes usar ambos al mismo tiempo.

¿Cuándo elegirías usar uno contra el otro? ¿Bajo qué circunstancias elegirías usar ambos juntos?

He estado evaluando estas opciones y esta es la conclusión a la que llegué.

MAF es un verdadero marco de complementos. Puede separar sus complementos por completo, incluso ejecutándolos dentro de un dominio de aplicación separado para que si un complemento falla, no eliminará su aplicación. También proporciona una forma muy completa de desacoplar los complementos de depender de cualquier cosa que no sea el contrato que les da. De hecho, puede versionar sus adaptadores de contrato para proporcionar compatibilidad con versiones anteriores de complementos antiguos mientras actualiza la aplicación principal. Si bien esto suena genial, viene con un alto precio que tiene que pagar para cruzar dominios de aplicaciones. Usted paga este precio en velocidad y también en la flexibilidad de los tipos que puede enviar de un lado a otro.

MEF se parece más a la inyección de dependencia con algunos beneficios adicionales, como la capacidad de detección y ... (dejando en blanco este). El grado de aislamiento que tiene MAF no está presente en MEF. Son dos marcos diferentes para dos cosas diferentes.

Lo que dijo Danielg es bueno. Yo podria agregar:

Si mira los videos sobre System.Addins, claramente están hablando de proyectos muy grandes. Habla sobre un equipo que administra la aplicación host, otro equipo que administra cada Complemento y un tercer equipo que administra el contrato y la tubería. Basado en eso, creo que System.Addins es claramente para aplicaciones más grandes. Estoy pensando en aplicaciones como los sistemas ERP como SAP (tal vez no sea tan grande, pero se entiende). Si vio esos videos, puede decir que la cantidad de trabajo para usar System.Addins es muy grande. Funcionaría bien si tuviera muchas compañías programando 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 complementos de SharpDevelop, la arquitectura del complemento Eclipse o Mono.Addins. Es mucho más fácil de entender que System.Addins y creo que es mucho más flexible. Lo que pierde es que no obtiene el aislamiento de AppDomain o los contratos de versiones fuertes listos para usar con MEF. Las fortalezas de MEF son que puede estructurar toda su aplicación como una composición de partes, para que pueda enviar su producto en diferentes configuraciones para diferentes clientes, y si el cliente compra una nueva característica, simplemente suelta la parte de esa característica en su directorio de instalación y la aplicación lo ve y lo ejecuta. También facilita las pruebas. Puede crear una instancia del objeto que desea probar y alimentarlo con objetos simulados para todas sus dependencias,

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

Haber desarrollado y enviado una aplicación MAF. Mis puntos de vista sobre MAF están algo cansados.

MAF es un sistema "desacoplado" o un sistema "desacoplado" en el peor de los casos. MEF es un sistema "acoplado" o un sistema "de acoplamiento flexible" en el mejor de los casos.

Los beneficios de MAF que obtuvimos al usar MAF son:

1. Instalación de componentes nuevos o actualizados mientras la aplicación se está ejecutando. El complemento podría actualizarse mientras la aplicación se estaba ejecutando y las actualizaciones aparecen al usuario sin problemas. Tienes que tener AppDomains para eso.

2. Licencias basadas en componentes comprados. Podríamos controlar qué complemento se cargó por la función y los permisos del usuario y si el complemento 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 Agile, el equipo de desarrollo desarrolló un AddIn a la vez sin tener que desarrollar también la pieza de integración con el resto de la aplicación.

4. Control de calidad mejorado (solo control de calidad de un componente a la vez). El control de calidad podría 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 complemento e instalar el archivo. ¡No fueron necesarias otras consideraciones!

6. Nuevos componentes trabajados con componentes viejos. El complemento que se desarrolló desde el principio siguió funcionando. Nuevos AddIns encajan perfectamente en la aplicación

En mi opinión, las dos tecnologías apuntan a casos de uso muy diferentes.

MEF suele ser el 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 garantizando la integridad general, pero tiene la necesidad de tener diferentes implementaciones de capacidades clave.

MAF es para un escenario en el que 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 host. En este escenario, la necesidad es de mecanismos más elaborados para "proteger" al host de complementos no autorizados (o para proteger complementos entre sí).

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

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

Además de los puntos planteados por las otras respuestas, parece que una de las diferencias clave entre MEF y MAF es que el Marco de Extensibilidad Administrada permitiría que una parte compostable dependa de otra. Permitiría que un complemento dependa de otro complemento, por ejemplo.

El Marco de Extensibilidad Administrada tampoco distingue realmente entre el host y el complemento, como lo hace System.AddIn. En lo que respecta a MEF, todas son partes componibles.

En mi opinión, la mejor manera de descubrir las diferencias es con 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: calculadora ejemplo simple que utiliza partes del MEF
( M anaged E xtensibility M ARCO)

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

• MEF no necesita tener una estructura de directorio específica, es simple y directo de usar, incluso para proyectos pequeños. Se trabaja con los atributos, para declarar lo que se exporta, lo que 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 se ocupa automáticamente del control de versiones

MAF: Calculadora simple con V1 y V2 versión plugins MAF
( M anaged Un ddin M ARCO)

• Muestra cómo construir la calculadora usando un complemento V1 y luego cómo pasar a un complemento V2 mientras se mantiene la compatibilidad con versiones anteriores ( nota: puede encontrar la versión V2 del complemento aquí , el enlace en el artículo original está roto)
• MAF aplica una estructura de directorio específica , y necesita mucho código repetitivo para que funcione, por lo tanto, 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 detenidamente 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: los complementos MAF están desacoplados, los componentes MEF están acoplados de forma flexible; MAF "Activa" (nueva instancia) mientras que MEF crea instancias por defecto.

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