verificando Entiendo la diferencia entre IoC, Ioc Container, DI y el localizador de servicio

Question

lea muchas publicaciones sobre la diferencia entre las 3 expresiones idiomáticas. Pero me confundí más, entonces me encontré con este artículo: http://martinfowler.com/articles/injection.html

solo quiero ver si lo tengo bien. Por favor corrígeme si estoy equivocado. Por favor, notificarme de las adiciones y corrección:

COI es el concepto de desvincular una aplicación de la implementación de un servicio que utiliza. La aplicación contiene una referencia a Iservice y no se encarga de la instanciación del servicio concreto.

Hay al menos dos vías para achive manera:

1. DI - El servicio concreto se inyecta como un parámetro ctor/lanzar una inyección interfaz colocador/tiro (lo que hace esto último quiere decir?)

2. ServiceLocator - es un componente que conoce todos los servicios concretos que la aplicación puede necesitar. La aplicación solicita explícitamente el servicio concreto del Localizador.

* El contenedor de IoC es realmente una fábrica de controles ("proveedor").

Me confundí un poco por la parte "cuando preferir (1) o (2)" en el artículo. ¿podría alguien contar por su propia experiencia en palabras simples?

"Service Locator tiene una ligera ventaja debido a su comportamiento más directo. Sin embargo, si está creando clases para usar en múltiples aplicaciones, entonces Dependency Injection es una mejor opción." -> ¿Cómo es el localizador más directo? porque usa la invocación de método explícitamente? ¿Qué es mejor usar DI cuando hay múltiples aplicaciones?

Answer 1

IoC es el concepto de desacoplamiento de una aplicación de la implementación de un servicio que utiliza.

Es cierto que IoC va de la mano con las interfaces de desacoplamiento de las implementaciones, pero lo veo como un principio más general. This SO answer da una muy buena explicación del concepto.

Hay al menos dos vías para achive manera:
1) DI
2) ServiceLocator

Yo no diría que el patrón Service Locator es un ejemplo de Inversión de Control. Todo lo contrario: cuando está utilizando el Localizador de servicios, está adquiriendo las dependencias requeridas de forma activa, nadie más lo hace por usted (a diferencia de la DI, donde el contenedor maneja las dependencias por usted, solo tiene que darle una posibilidad de hacerlo - un setter, un parámetro de constructor o implementando un método de interfaz de inyección).

¿Cómo es el localizador más sencillo? porque usa la invocación de método explícitamente?

Creo que Martin Fowler se está refiriendo a la idea general de IoC que puede hacer que el código sea más difícil de entender si nunca ha visto el concepto de IoC/DI utilizado anteriormente. Por otro lado, el código que usa Service Locator para adquirir algunas dependencias puede ser más fácil de comprender en el primer encuentro.

¿Qué es mejor usar DI cuando hay múltiples aplicaciones?

Cuando se crea un componente que se supone que es reutilizable, la ventaja de DI es que no tiene su componente depende de nada más que la dependencia original (en el ejemplo de MF, la MovieLister sólo depende la interfaz MovieFinder cuando se usa DI). Además, es bastante fácil para otros usar su componente; solo tiene que pasar las dependencias usando los medios de DI que usted proporcionó.

Al utilizar el Localizador de servicios, también agrega dependencia en la interfaz del Localizador de servicios. Con la interfaz segregada para el localizador, eso puede no ser un problema. Pero también puede ser más difícil para los usuarios de su componente para satisfacer las dependencias de su componente, como MF escribe:

La diferencia viene si el lister es un componente que estoy proporcionando a una aplicación que otras personas están escritura. En este caso, no sé mucho sobre las API de los localizadores de servicios que mis clientes van a utilizar. Cada cliente puede tener sus propios localizadores de servicios incompatibles.