Elegir entre MEF y MAF (System.AddIn)

StackOverflow https://stackoverflow.com/questions/835182

Pregunta

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 Stack Overflow, ¿Es MEF un reemplazo para System.Addin? , incluso puedes usar ambos al mismo tiempo.

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

¿Fue útil?

Solución

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 das. De hecho, puede versionar sus adaptadores de contrato para proporcionar compatibilidad con versiones anteriores de los complementos antiguos mientras actualiza la aplicación principal. Si bien esto suena genial, viene con un alto precio que tienes 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.

Otros consejos

Lo que dijo Danielg es bueno. Yo agregaría:

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 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 compañías que programen complementos de terceros para su sistema y no pueda 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, 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 estar 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 "desacoplado" sistema o "acoplado libremente" sistema en el peor. MEF está acoplado sistema o "pareja suelta" sistema 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. Los nuevos componentes funcionaron con componentes antiguos. El complemento que se desarrolló desde el principio siguió funcionando. Los nuevos AddIns se ajustan perfectamente a la aplicación

En mi opinión, las dos tecnologías en realidad 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 necesita 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" el 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 donde el host / aplicación necesita absolutamente una capacidad y la necesidad es realmente especificar diferentes implementaciones a través de la configuración.

Acabo de encontrar este extenso 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 formulados 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: Ejemplo de calculadora simple usando partes MEF
( M anaged E xtensibility F ramework)

  • 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 catalog.Catalogs.Add (new DirectoryCatalog (" Plugins " ;, " *. dll ")); en lugar de usar catalog.Catalogs.Add (new AssemblyCatalog (typeof (Program) .Assembly)); y extraiga el código de la calculadora y contrato para separar proyectos DLL.)

  • MEF no necesita tener una estructura de directorio 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 comprender. Ejemplo: [Exportar (typeof (IOperation))] [Exportar metadatos (" Símbolo " ;, '+')] clase Add: IOperation {     public int Operate (int izquierda, int derecha)     {         volver izquierda + derecha;     } }

  • MEF no se ocupa automáticamente del control de versiones

MAF: Calculadora simple con 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 mientras se mantiene la compatibilidad con versiones anteriores ( nota: puede encontrar la versión V2 del complemento < a href = "https://msdn.microsoft.com/en-us/library/vstudio/bb384194(v=vs.100).aspx" rel = "noreferrer"> aquí , el enlace en el original el artículo está roto)
  • MAF impone 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 libremente; 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.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top