¿Cómo está utilizando el marco de extensibilidad administrado?

He estado trabajando con MEF durante aproximadamente 2 semanas. Comencé a pensar para qué sirve MEF, investigé para descubrir cómo usar MEF y finalmente implementé un Host con 3 módulos. Los contratos están demostrando ser fáciles de entender y los módulos se gestionan fácilmente.

Aunque MEF tiene un uso muy práctico, me pregunto en qué medida. Quiero decir, ¿todos reescribirán las aplicaciones existentes para la extensibilidad?

Sí, eso suena y es increíblemente poco práctico. Hablando retóricamente:

• ¿Cómo está afectando MEF las tendencias actuales en la programación?

• ¿Has comenzado a buscar oportunidades para usar MEF?

• ¿Has comenzado a planificar una reescritura importante de una aplicación existente que pueda beneficiarse de la extensibilidad?

Dicho esto, mis preguntas son:
¿cómo sé cuándo debo planificar un nuevo proyecto con extensibilidad?
¿Cómo sabré si un proyecto existente necesita ser reescrito para la extensibilidad?

¿Alguien está usando MEF?

¿Alguien está usando MEF?

Estoy trabajando en un proyecto de Silverlight usando el patrón MVVM. Comenzamos simplemente conectando todas las máquinas virtuales juntas según sea necesario a través de las interfaces y la inyección de dependencia manual (ya sea la inyección del constructor o de la propiedad dependiendo de la necesidad). Comenzó a ser doloroso, y comenzamos a usar MEF como un marco de inyección de dependencia para exportar ciertos servicios que se utilizan en los modelos de vista e importarlos en los modelos de vista que los necesitan. Funciona perfectamente y con muy poco código.

Sí, hay algunos puristas que dicen que MEF no está destinado a la inyección de dependencia y que un marco de inyección de dependencia real será mucho mejor. Sin embargo, MEF está integrado directamente en .NET, lo cual es una gran ventaja, y fue suficiente para satisfacer nuestras necesidades.

¿Cómo sé cuándo debo planificar un nuevo proyecto con extensibilidad? ¿Cómo sabré si un proyecto existente necesita ser reescrito para la extensibilidad?

En mi opinión, siempre debe separar las preocupaciones de manera apropiada y usar interfaces para permitir que los diferentes módulos cambien de forma independiente. Si hace esto correctamente, cuando encuentre una necesidad de extensibilidad, MEF debería ser fácil de agregar. Pero no comenzaría un proyecto que no tuviera requisitos de extensibilidad y pondría a MEF por si acaso. Esperaría a que haya una necesidad. Para los proyectos existentes, si surge una necesidad, evaluaría el esfuerzo de volver a cablear el proyecto para usar MEF versus soluciones alternativas versus no hacer nada, y ver qué gana.

El error que comete la gente, y creo que se debe a la denominación ( marco de extensibilidad administrada ) es asumir que MEF solo es práctico para la extensibilidad. MEF realmente aborda tres cosas clave: extensibilidad, descubrimiento y metadatos. Los dos últimos son muy potentes incluso para una aplicación que nunca verá un solo complemento o extensión.

Este es un artículo que escribí sobre su poder para el descubrimiento como contenedor de COI: http://www.informit.com/articles/article.aspx?p=1635818

Utilizo MEF en la mayoría de las aplicaciones empresariales de la línea de negocios porque hace que sea más rápido y fácil construir y mantener aplicaciones modulares en Silverlight.

Actualmente estoy usando MEF en algunos proyectos que incorporan el patrón Repository.

Uno está usando diferentes tipos de repositorios durante las pruebas unitarias, el otro proyecto está usando repositorios locales (directos a DB), remotos (WCF) y de prueba.

Ambos proyectos pueden cambiar sus tipos de repositorio a través de código o configuración, y se basa en metadatos MEF / tipos diferidos.

Hasta la fecha, ambos proyectos se ejecutan increíblemente bien.