El Managed Extensibility Framework (MEF) y el Framework administrado AddIn (MAF, también conocido como System.AddIn) parecen llevar a cabo tareas muy similares. De acuerdo con esta pregunta sobre desbordamiento de pila, Is MEF a replacement for System.Addin?, puede usar ambos al mismo tiempo.Elegir entre MEF y MAF (System.AddIn)
¿Cuándo elegiría usar uno frente al otro? ¿En qué circunstancias elegirías usar ambos juntos?
He estado evaluando estas opciones y esta es la conclusión a la que he llegado.
MAF es un verdadero framework de complementos. 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.
Lo que Danielg dijo es bueno. Agregaría:
Si mira los videos sobre System.Addins, están hablando claramente de proyectos muy grandes. Habla de un equipo administrando la aplicación de host, otro equipo administrando cada complemento, y un tercero equipo administrando el contrato y la canalización. 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 gente usándolo, 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 (incluido yo mismo). Creo que eso te dice algo sobre los dos marcos.
"Si miras los videos sobre System.Addin", ¿Qué videos? Podría dar el enlace. Gracias – Arjang
@Arjang: hay un par en el canal 9. Pruebe http://channel9.msdn.com/Blogs/DanielMoth/Administración-AddIn-Framework –
En mi opinión, las dos tecnologías se dirigen realmente 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 necesita implementar diferentes capacidades clave.
MAF es para un escenario donde alguien/grupo está desarrollando una plataforma o host y otros grupos agregarán capacidades después de los hechos 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.
Acabo de encontrar este extenso artículo sobre MAF y MEF. http://emcpadden.wordpress.com/2008/12/07/managed-extensibility-framework-and-others/
Además de los puntos señalados por las otras respuestas, suena como si una de las principales diferencias entre el MEF y MAF es que el marco de extensibilidad Gestionado permitiría una parte componibles a depender de otro. 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.
Haber desarrollado y enviado una aplicación MAF. Mis puntos de vista sobre MAF son algo hastiados.
MAF es un sistema "desacoplado" o sistema "débilmente acoplado" en el peor. MEF es un sistema "acoplado" o un sistema de "pareja suelta" en el mejor de los casos.
beneficios MAF que realizamos mediante el uso de MAF son:
Instalación nueva o actualizar los componentes existentes mientras se ejecuta la aplicación. 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.
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.
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.
QA mejorado (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.
Despliegue (agregue los componentes a medida que se desarrollan y lanzan y que "simplemente funcionan"). La implementación es solo una cuestión de hacer un AddIn e instalar el archivo. ¡Ninguna otra consideración era necesaria!
Los nuevos componentes funcionan con componentes antiguos. AddIn que se desarrolló al principio siguió trabajando.Nuevos AddIns encajan en la aplicación sin problemas
He hecho todo lo anterior con MEF en .NET 4 y yo es más simple que MAF ... – Tim
@Jim: ¿puede desinstalar un complemento MEF existente mientras se ejecuta? Por lo que yo sé, el conjunto de complemento no se puede descargar una vez cargado, debido a que está en el mismo dominio de la aplicación. –
@Scott - +1 (¿puedo dar más de uno?) Otro beneficio no enumerado aquí: Puede proteger los derechos de seguridad del complemento usando MAF, mientras que los derechos de seguridad utilizados por un componente en MEF compartirán los mismos derechos que el ejecución de la aplicación. – Doug
En mi opinión, la mejor manera de descubrir las diferencias es manos a la código. He encontrado dos MSDN tutoriales, ambos con un ejemplo calculadora para que pueda comparar fácilmente sus implementaciones:
MEF:Simple calculator example using MEF parts
(M anaged E xtensibility F ARCO)
catalog.Catalogs.Add(new DirectoryCatalog("Plugins", "*.dll")); en lugar de utilizar catalog.Catalogs.Add(new AssemblyCatalog(typeof(Program).Assembly)); y extraer el código calculadora y contrato para proyectos DLL separados.)MEF no lo hace necesidad de contar con una estructura de directorios específica, es simple y directo de usar, incluso para proyectos pequeños. Es 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; } }
MEF no se ocupa automáticamente con el control de versiones
MAF:Simple calculator with V1 and V2 version MAF plugins
(M anaged A ddin F ARCO)
Pipeline AddIns CalcV1 CalcV2 AddInSideAdapters AddInViews Contracts HostSideAdapters
Tanto MEF y MAF están incluidos en el 4.x. .NET Framework 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.
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 puede utilizar genéricos para hacer genéricos 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.
una pequeña cosa: recuerde que "dominio de aplicación separado" NO lo ayudará si su complemento se bloquea en una capa nativa, para eso todavía necesitará procesos de trabajo. MAF ayuda un poco con la creación de ellos, pero la recuperación dinámica de ese bloqueo sigue siendo bastante difícil (pero posible) – quetzalcoatl
@Ian: por favor, vuelva a leer mi comentario :) He escrito exactamente eso, y MÁS: MAF realmente lo permite, pero tiene que levántese después del accidente por su cuenta. – quetzalcoatl
@DanielG> tiene un alto precio que pagar para poder acceder a aplicaciones <¿Por qué es esto? ¿Qué tan "pesado"? –