.net - Elegir entre MEF y MAF(System.AddIn)

add-in

Question

El Framework de Extensibilidad Administrada (MEF) y el Framework Administrado de Complementos (MAF, también conocido como System.AddIn) parecen llevar a cabo tareas muy similares. Según esta pregunta sobre el desbordamiento de la pila, ¿MEF es un reemplazo para System.Addin? , incluso puedes usar ambos al mismo tiempo.

¿Cuándo elegirías usar uno frente a otro? ¿En qué circunstancias elegirías usar ambos juntos?

Answer 1

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

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

El Framework de Extensibilidad Administrada tampoco hace distinciones entre el host y el complemento, como lo hace System.AddIn. En lo que respecta a MEF, todos son solo partes compostables.

Answer 2

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

MEF: Ejemplo simple de calculadora usando partes MEF
( F uncionamiento de la E xtensibilidad M anagerado)

• Muestra cómo construir una calculadora simple usando tecnología MEF. No muestra cómo cargar dlls externos. (Pero puede simplemente modificar el ejemplo utilizando 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 proyectos de DLL por separado).

• MEF no necesita tener una estructura de directorio específica, es simple y fácil de usar, incluso para proyectos pequeños. Funciona con atributos, para declarar lo que se exporta, lo que es fácil de leer y comprender. Ejemplo: [Export(typeof(IOperation))] [ExportMetadata("Symbol", ''+'')] class Add: IOperation { public int Operate(int left, int right) { return left + right; } } [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 la versión V1 y V2 Complementos MAF
( M anaged A ddin F ramework)

• Muestra cómo construir la calculadora usando un complemento V1 y luego cómo pasar a un complemento V2 manteniendo la compatibilidad con versiones anteriores ( nota: aquí puede encontrar la versión V2 del complemento, el enlace en el artículo original está roto)
• MAF impone una estructura de directorio específica , y necesita una gran cantidad de 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 de MAF tienen mucha más complejidad en comparación con el marco de MEF, por lo que debe pensar cuidadosamente cuándo utilizar qué marcos.

Answer 3

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

MEF suele ser mejor en un escenario de inyección de dependencia pura donde la persona o grupo que entrega la solución integrada final ensambla todo y garantiza 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 de host. En este escenario, la necesidad es de mecanismos más elaborados para "proteger" al host de los add-ins deshonestos (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 donde el host / la aplicación necesita absolutamente una capacidad y la necesidad es realmente especificar diferentes implementaciones a través de config.

Answer 4

Habiendo desarrollado y enviado una aplicación MAF. Mis puntos de vista sobre MAF son algo hastiados.

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

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

1. Instalar nuevos o actualizar componentes existentes mientras la aplicación se está ejecutando. El complemento podría actualizarse mientras se ejecuta la aplicación y las actualizaciones se muestran al usuario sin problemas. Tienes que tener AppDomains para eso.

2. Licencia basada en componentes comprados. Podríamos controlar qué AddIn fueron cargados por el rol y los permisos del usuario y si el AddIn fue licenciado para su uso.

3. Desarrollo rápido (tiempo de comercialización más rápido). El desarrollo 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. Mejora de QA (solo control de calidad de 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. Despliegue (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. ¡Ninguna otra consideración era necesaria!

6. Los nuevos componentes funcionaban con componentes antiguos. AddIn que se desarrolló al principio siguió trabajando. Las nuevas adiciones se ajustan perfectamente a la aplicación

Answer 5

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

MAF es un verdadero marco de complemento. Puedes separar completamente tus complementos, incluso ejecutarlos dentro de un dominio de aplicación separado, de modo que si un complemento se bloquea, no eliminará tu aplicación. También proporciona una forma muy completa de desacoplamiento de los complementos dependiendo de cualquier cosa que no sea el contrato que les brinde. De hecho, puede versionar sus adaptadores de contrato para proporcionar compatibilidad hacia atrás con los complementos antiguos mientras actualiza la aplicación principal. Si bien esto suena muy bien, tiene que pagar un alto precio para cruzar dominios de aplicaciones. Usted paga este precio en velocidad y también en la flexibilidad de los tipos que puede enviar de ida y vuelta.

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

Answer 6

Lo que Danielg dijo es bueno. Yo podria agregar:

Si mira los videos sobre System.Addins, claramente están hablando de proyectos muy grandes. Habla de un equipo que administra la aplicación de host, otro equipo que administra cada AddIn y un tercer equipo que administra el contrato y el pipeline. 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 tan grande, pero entiendes la idea). Si vio esos videos, puede decir que la cantidad de trabajo para usar System.Addins es muy grande. Funcionaría bien si tuviera muchas empresas programando complementos de terceros para su sistema y no puede romper ninguno de esos contratos adicionales bajo pena de muerte.

Por otro lado, MEF parece compartir más similitudes con el esquema de complemento 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 ni los contratos de versiones fuertes listos para usar con MEF. Los puntos fuertes de MEF son que puede estructurar toda su aplicación como una composición de partes, por lo que puede enviar su producto en diferentes configuraciones para diferentes clientes, y si el cliente compra una nueva característica, simplemente deja caer la parte para esa característica en su directorio de instalación y la aplicación lo ve y lo ejecuta. También facilita las pruebas. Puede instanciar el 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 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 para ser incluido en .NET 4, y la gente ya está empezando a crear muchas aplicaciones (yo incluido). Creo que eso te dice algo sobre los dos marcos.

Answer 7

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: las adiciones de MAF están desacopladas, los componentes de MEF están sueltos; MAF "Activa" (nueva instancia) mientras que MEF realiza instancias por defecto.

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