¿Cuándo es apropiado usar IoC?

Question

Entiendo qué contenedores de IoC son y he estado leyendo en Structure Map. La tecnología parece bastante fácil de usar. Mi pregunta es, ¿cuál es el nivel apropiado de granularidad para usar un contenedor IoC?

veo los siguientes niveles posibles de aplicación de la COI:

1. descanso cada dependencia entre todos los objetos - ciertamente una exageración.
2. Rompe las dependencias entre todos los objetos principales, como objetos de dominio, clases de soporte y componentes dentro de subsistemas.
3. Utilice IoC junto con una Fachada para envolver un subsistema (como el registro) con una interfaz pública y luego romper la dependencia de esa interfaz.

Sé que la respuesta a esta pregunta es "depende", pero según su experiencia, ¿de qué depende la respuesta? ¿El tamaño del proyecto es un factor?

Además, ¿dónde no tiene sentido usar IoC?

Answer 1

La idea no es romper las dependencias entre los objetos de dominio, es proteger su dominio del mundo exterior. Los objetos de su dominio deben referirse a cualquier problema comercial que esté resolviendo y no a bases de datos, registro, almacenamiento en caché, contextos HTTP, servicios de descanso, etc.

Este artículo habla acerca de mover responsabilidades de sus objetos al contenedor IoC.

http://www.agileatwork.com/captcha-and-inversion-of-control/

Answer 2

Creo que tiene sentido usarlo cuando sabe que va a escribir muchas pruebas unitarias, ya que facilita la construcción de esas pruebas. Además, le permite (a través de una configuración externa) cambiar el comportamiento de los objetos durante el tiempo de ejecución.

No tiene sentido utilizar IoC en proyectos más pequeños o proyectos que no necesitan un desacoplamiento masivo.

Answer 3

Yo diría que tiene más sentido cuando sabes que necesitarás una aplicación flexible porque los requisitos cambiarán a menudo, o cuando trabajarás en un sistema grande con un equipo de desarrolladores. Ayuda trabajar en equipo porque puedes trabajar en tu trabajo y dejar que IoC se encargue de tus dependencias.

Answer 4

Un escenario para COI es cuando una decisión de implementación específica es impugnada entre el equipo de desarrollo. IOC ofrece la flexibilidad de poder intercambiar implementaciones con una fricción mínima. Esto es más una consideración táctica que nada.

Answer 5

Bueno, COI no tiene mucho sentido si se está programando un componente muy concreto que no va a tener varios tipos de implementaciones ...

Por ejemplo; Supongamos que está programando un lector de documentos para su empresa y sabe con certeza que la regla comercial detrás del lector es que nunca leerá ningún otro tipo de documento, sino un documento de MS Word. En este caso, las pruebas de su unidad realmente no requieren un acoplamiento flexible de la inyección de dependencia porque el componente que está probando nunca dependerá de otra cosa que no sea un documento de MS Word. Puede ser exagerado utilizar un contenedor IOC para resolver el tipo de lector.