Usando MEF como IoC

Question

Después de leer algunas cosas como esta: http://mikehadlow.blogspot.com/2008/09/managed-extensibility-framework-why.html

entiendo que el MEF tiene algunas featcures que no voy a encontrar en un COI, y que el MEF tiene algunas cosas COI que probaboly no es tan avanzada como algunos otros sistemas de IoC pueden ofrecer.

Necesito las cosas de MEF. ¿También necesito un marco de IoC o estaré bien con lo que MEF tiene?

Asher

Answer 1

Depende de sus requisitos/código existente.

Si tiene una infraestructura de código existente construida en un contenedor IoC, puede combinarlas con MEF. Recientemente, he estado creando un marco ASP.NET MVC + MEF, y algunos de mis lectores han estado preguntando cómo integrar Unity con el marco MEF + MVC que he creado. Esto resultó ser realmente fácil, gracias a un proyecto llamado Common Services Locator.

El proyecto CSL está diseñado para proporcionar una abstracción sobre la ubicación del servicio, así puedo tomar un proveedor CSL para Unity, conectarlo con un ExportProvider personalizado y MEF automáticamente comienza a componer mis partes IoC-driven.

Este es uno de los beneficios del modelo ExportProvider de MEF, puede conectar fácilmente cualquier proveedor adicional para comenzar a extraer exportaciones de una variedad de fuentes.

La semana pasada I blogged about combining MEF+Unity (y también MEF + Autofac como otro ejemplo), y aunque mis ejemplos están preparados para ASP.NET MVC, el concepto es el mismo para la mayoría de las otras implementaciones.

Si tiene la opción de crear algo nuevo usando MEF, probablemente no necesite un contenedor IoC, MEF puede administrar la inyección de propiedad, la inyección del constructor, la administración de la vida útil de la pieza y la resolución de tipo.

Déjeme saber si usted tiene alguna pregunta :)

Answer 2

Un COI sigue un propósito.

MEF especialmente está bien diseñado, si desea tener algún tipo de complementos en su sistema. o código en el que no confíes para ejecutarse correctamente (no te olvides de manejar excepciones).

pero, por lo tanto, viene con una sobrecarga.

si solo desea hacer IoC, ya que es un buen patrón de diseño para software extensible y comprobable, entonces recomendaría AutoFac, ya que es del mismo tipo. más o menos :-)

y, si necesita ambas intenciones. luego use Ambos. como Matthew señaló, puedes usar el CSL para abstraer ambos. si lo desea

para los plugins -> MEF

para su COI -> una sencilla COI

Answer 3

Utilizamos MEF como un contenedor COI y que está trabajando para nosotros.

Dicho esto, usted debe echar un vistazo a esta entrada del blog de Glenn bloque en el que se enumeran los inconvenientes que pueden surgir: Should I use MEF for my general IoC needs?

Answer 4

estoy usando MEF tanto para la extensibilidad y la COI en SoapBox Core. También hay un artículo sobre CodeProject llamado Building an Extensible Application with MEF, WPF, and MVVM que describe cómo funciona.

Answer 5

Estaba usando el modelo de proveedor para esencialmente "IOC" en la aplicación web antes de cambiar a AutoFac recientemente.

Básicamente mi requisito es que tengo que poder "vender" aplicaciones, por lo que las interfaces deben abstraerse. Al usar el Modelo de Proveedor, las cosas tienden a complicarse. Usar un contenedor IOC (si ya está) tiene más sentido, y aún puedo cumplir con mis requisitos de "venta directa" porque el contenedor IOC se puede "reconfigurar" para permitir diferentes implementaciones.

Creo que MEF sería la mejor solución si quiere una base de código limpia porque tiene más convenciones, por lo que esencialmente las personas podrían soltar componentes en una carpeta y no cambiar ninguna configuración para provocar cambios. Esto es bueno, pero posiblemente exagerado para mi escenario donde una anulación simple de configuración es suficiente.

Leer más en mi blog - esperemos que el blog va a conseguir algunos buenos comentarios sobre él también: http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html