inversion-of-control - ioc - inversion of control vs dependency injection

MEF vs. cualquier IoC

Question

En cuanto al Marco de Extensibilidad Administrada de Microsoft (MEF) y varios contenedores de IoC (como Unity), no veo cuándo usar un tipo de solución sobre la otra. Más específicamente, parece que MEF maneja la mayoría de los patrones tipo IoC y que un contenedor IoC como Unity no sería tan necesario.

Idealmente, me gustaría ver un buen caso de uso en el que se use un contenedor IoC en lugar de, o además de, MEF.

Answer 1

Cuando se reduce, la principal diferencia es que los contenedores de IoC son generalmente más útiles con dependencias estáticas (conocidas en tiempo de compilación), y MEF generalmente es más útil con dependencias dinámicas (conocidas solo en tiempo de ejecución).

Como tal, ambos son motores de composición, pero el énfasis es muy diferente para cada patrón. Las decisiones de diseño varían mucho, ya que MEF se optimiza en torno al descubrimiento de piezas desconocidas, en lugar de registros de piezas conocidas.

Piénselo de esta manera: si está desarrollando toda su aplicación, un contenedor IoC es probablemente el mejor. Si está escribiendo para la extensibilidad, de modo que los desarrolladores de terceros extenderán su sistema, MEF probablemente sea el mejor.

Además, el artículo en la respuesta de @Pavel Nikolov proporciona una gran dirección (está escrito por Glenn Block, gerente de programa de MEF).

Answer 2

Estoy de acuerdo en que el MEF puede ser un marco de IoC totalmente capaz. De hecho, estoy escribiendo una aplicación en este momento, basada en el uso de MEF tanto para extensibilidad como para IoC. Tomé las partes genéricas y lo convertí en un "marco" y lo abrí como su propio marco llamado SoapBox Core en caso de que la gente quiera ver cómo funciona.

En particular, observe cómo funciona el Host si desea ver a MEF en acción.

Answer 3

He estado usando MEF por un tiempo y el factor clave para cuando lo usamos en lugar de productos IOC es que regularmente tenemos 3-5 implementaciones de una interfaz determinada en nuestro directorio de complementos en un momento dado. Cuál de esas implementaciones se debe usar es en realidad algo que solo se puede decidir en tiempo de ejecución.

MEF es bueno para dejarte hacer eso. Por lo general, IOC está orientado a garantizar que se pueda cambiar, en un ejemplo cononical, un IUserRepository basado en ORM Product 1 para ORM Product 2 en algún momento en el futuro. Sin embargo, la mayoría de las soluciones de IOC asumen que solo habrá un IUserRepository en vigencia en un momento dado.

Sin embargo, si necesita elegir uno basado en los datos de entrada para una solicitud de página determinada, los contenedores de IOC suelen tener pérdidas.

Como ejemplo, hacemos nuestra verificación de permisos y nuestra validación a través de los complementos de MEF para una gran aplicación web en la que he estado trabajando durante un tiempo. Usando MEF, podemos ver cuándo fue la fecha CreatedOn del registro e ir a buscar el complemento de validación que estaba en efecto cuando se creó el registro y ejecutar el registro AMBOS a través de ese complemento Y el validador actualmente en vigencia y comparar la validez del registro hora.

Este tipo de poder también nos permite definir anulaciones de paso a paso para los complementos. Las aplicaciones en las que estoy trabajando son en realidad la misma base de código implementada para más de 30 implementaciones. Por lo tanto, normalmente buscamos complementos al solicitar:

1. Una implementación de interfaz que es específica para el sitio actual y el tipo de registro específico en cuestión.
2. Una implementación de interfaz que es específica del sitio actual, pero funciona con cualquier tipo de registro.
3. Una interfaz que funciona para cualquier sitio y cualquier registro.

Eso nos permite agrupar un conjunto de complementos predeterminados que se activarán, pero solo si esa implementación específica no lo anula con las reglas específicas del cliente.

IOC es una gran tecnología, pero realmente parece tener más que ver con hacer que sea fácil codificar las interfaces en lugar de las implementaciones concretas. Sin embargo, intercambiar esas implementaciones es más un tipo de evento de cambio de proyecto en IOC. En MEF, usted toma la flexibilidad de las interfaces y las implementaciones concretas y la convierte en una decisión de tiempo de ejecución entre muchas opciones disponibles.

Answer 4

Me disculpo por estar fuera del tema. Simplemente quería decir que hay 2 defectos que hacen que MEF sea una complicación innecesaria:

• se basa en un atributo que no sirve de nada para ayudarte a descubrir por qué las cosas funcionan como lo hacen. No hay forma de llegar a los detalles ocultos en el interior del marco para ver qué está sucediendo exactamente allí. No hay forma de obtener un registro de seguimiento o conectarlo a los mecanismos de resolución y manejar situaciones no resueltas manualmente

• no tiene ningún mecanismo de resolución de problemas para descubrir las razones por las cuales algunas partes son rechazadas. A pesar de señalar una parte que falla, no te dice por qué esa parte ha fallado.

Así que estoy muy decepcionado con eso. Pasé demasiado tiempo luchando contra molinos de viento tratando de arrancar algunas clases en lugar de trabajar en los problemas reales. Convencí de que no hay nada mejor que la técnica de inyección de dependencia de la vieja escuela cuando tienes control total sobre lo que se crea, cuándo y cómo rastrear algo en el depurador de VS. Desearía que alguien que defiende MEF presentara una serie de buenas razones en cuanto a por qué debería elegirlo en lugar de DI simple.