El uso de un contenedor IOC disminuirá la velocidad de su aplicación porque la mayoría usa reflexión debajo del capó. También pueden hacer que su código sea más difícil de entender (?). En el lado brillante; te ayudan a crear aplicaciones más flexibles y te hacen las pruebas unitarias más fáciles. ¿Hay otros pros y contras para usar/no usar un contenedor de IOC?¿Cuáles son los pros y los contras para usar un contenedor de IOC?
En la mayoría de los casos, ni siquiera notará una penalización de rendimiento, ya que para objetos "singleton" toda la inicialización se realiza una sola vez. También argumentaría que IoC hace que sea diferente entender el código: por el contrario, el desarrollo al estilo IoC te obliga a crear clases pequeñas y coherentes, que a su vez son más fáciles de asimilar.
Bueno, supongo que una estafa que he experimentado es que algunos desarrolladores no parecen ser capaces de comprender IoC. Hemos tenido algunas personas que estaban en contra por ninguna razón más que porque no las entendieron. (No dice que es una mala razón para estar en contra de algo, en absoluto.)
Añade un poco de abstracción que siempre parece lograr confundir a alguien, pero yo diría que los pros superan con creces los inconvenientes en la mayoría de los casos.
Si está utilizando un contenedor IOC de manera simple, la reflexión solo se usa al inicio: la aplicación está cableada para empezar y luego se ejecuta normalmente sin intervención del contenedor. Por supuesto, si está utilizando el COI para resolver dependencias después de que haya empezado a correr, puede ser un poco diferente, aunque aún esperaría que se resolviera con pereza y caché a menos que lo haya configurado para crear nuevas instancias cada una. hora.
En cuanto a hacer que el código sea más difícil de entender, ¡todo lo contrario! Con las dependencias explícitamente establecidas, es mucho más fácil comprender cada componente, y los archivos de configuración dejan en claro cómo la aplicación completa se junta.
Estoy de acuerdo con todas las respuestas hasta el momento.
Lo que me gustaría añadir es que crea un poco de sobrecarga, por lo que no es realmente adecuado para pequeñas aplicaciones.
Las aplicaciones medianas y grandes son las que más se benefician del uso de la IoC.
Es posible que también echa un vistazo a esta pregunta para obtener más información sobre los pros y contras: Castle Windsor Are There Any Downsides?
Creo que la suposición acerca de reducida velocidad de ejecución es mucho el mismo tipo de argumento como "C es más rápido que C#/Java". Si bien esta afirmación puede ser cierta para operaciones específicas y/o tareas estructuralmente simples, no es el caso en el momento en que aumenta la complejidad.
La forma en que las estructuras DI le permiten concentrarse en la creación de objetos y dependencias crea sistemas más eficientes cuando aumenta el tamaño del código. Para aplicaciones grandes, estoy casi seguro de que el código basado en DI-DI superará a cualquier solución alternativa. ¡Simplemente hay tan poca redundancia en el tiempo de ejecución que es difícil hacerlo más eficiente! La mayor parte de la sobrecarga adicional también es solo a primera carga.
Contenedores DI avanzados también le permiten hacer magia "alcance" que solo puede soñar sin el contenedor. El uso de proxies alcance, spring puede hacer lo siguiente:
A Singleton
|
B Singleton
|
C Prototype (per-invocation)
|
D Singleton
|
E Session scope (web app)
|
F Singleton
Eficacia con la que puede tener diez capas de objetos únicos y todo de una sesión repentina algo con ámbito aparece.
Las cosas como la seguridad se pueden inyectar de manera totalmente diferente a como lo haría de otra manera. A menudo hay una paradoja clásica: a menudo la capa de GUI necesita tener un conocimiento complejo de los permisos de seguridad. Con bastante frecuencia, la capa de servicios también necesita esto, pero a menudo con un nivel de detalle diferente (por lo general, menos detallado que la interfaz gráfica de usuario). El enfoque clásico sería enviarlo como parámetros, ponerlo en un threadlocal o pedir un servicio. Con la primavera, puede inyectarlo directamente donde lo necesita y nadie más necesita saberlo.
Esto realmente cambia el desarrollo de aplicaciones como un todo. Me costó mucho adaptarme a esto, pero después de este dolor, veo que está mucho más cerca de cómo deberían ser las cosas (en lugar de cómo hemos aprendido a hacerlo).
Así que creo que los frameworks DI tienen el potencial de cambiar la forma en que se crean los programas, con implicaciones mucho más amplias que solo DI. No es solo una forma glorificada de llamar al nuevo.
Creo que es justo decir que si tiene un conocimiento experto sobre cómo usar IOC y tiende a escribir un buen código de todos modos, entonces IOC hará que su código sea más fácil de entender en todos menos en los sistemas más pequeños.
Sin embargo, si trabaja en un lugar donde la mayoría de las clases/métodos son muy grandes y el concepto de refactorización aún no se ha establecido, entonces intentar usar un IOC probablemente dificulte la comprensión del software. El COI también debe ser apoyado por todos los que programan el proyecto, por lo que puede ser una consideración.
Veo al COI como la guinda del pastel; Me gusta la guinda pero solo en un buen pastel. Si el pastel no es bueno para empezar, primero ordena el pastel.
En cuanto a la sobrecarga de rendimiento del uso de IOC, no veo esto como un problema en la mayoría de los casos. La sobrecarga no necesita ser grande, y dada la velocidad de la CPU actual, la mayor parte del tiempo de ejecución probablemente sea acceso a datos de todos modos. Si un IOC demostró ser lento para un determinado bit de código, me gustaría añadir algo de almacenamiento en caché del objeto devuelto, o eliminar el IOC solo desde ese bit de código.
Si está escribiendo una aplicación comercial, usar un contenedor de inversión de control e inyección de dependencia (junto con otras prácticas y herramientas ágiles) lo ayudará en términos de productividad y confiabilidad.
Además, su aplicación probablemente pasará la mayor parte del tiempo de su CPU esperando recursos o esperando la interacción humana y sin hacer nada útil. Su aplicación debe tener una gran cantidad de caballos de sobra por unos pocos microsegundos de reflexión.
+1 por mucho sentido común en su respuesta. –
Una vez que está utilizando un contenedor IoC, el código es más fácil de entender. Sin embargo, antes de que lo usen, puede ser difícil para algunos desarrolladores entender por qué lo necesitan. Los problemas de complejidad que resuelve generalmente no están presentes en las aplicaciones de juguetes. – Anthony
Estoy de acuerdo y en desacuerdo: los fragmentos independientes son más fáciles de entender de forma aislada. Pero toda la imagen y el cableado son más difíciles. Ejemplo: Está leyendo el código fuente de un servicio que llama a un método de guardado de repositorio. Le pregunto a su editor "goto definition of save" que termina en la definición de interfaz pero no en la implementación concreta utilizada. – k3b
@ k3b: Claro, entonces también necesita tener una vista de la tubería ... pero no creo que eso sea un impedimento suficiente para que valga la pena acoplar estrechamente diferentes servicios entre sí. –