Zenject: cómo un contenedor de IoC puede matar la inyección de dependencia en su proyecto

¿Dónde comienza el peligro? Suponga que está firmemente decidido a desarrollar un proyecto, adhiriéndose a un concepto o enfoque específico. En nuestra situación, esto es DI, aunque la programación reactiva, por ejemplo, también puede estar en su lugar. Es lógico que para lograr su objetivo, recurra a soluciones preparadas (en nuestro ejemplo, el contenedor DI Zenject). Se familiarizará con la documentación y comenzará a construir el marco de la aplicación utilizando la funcionalidad principal. Si en las primeras etapas del uso de la solución no tiene sensaciones desagradables, lo más probable es que permanezca en su proyecto durante toda su vida. A medida que trabaje con las funciones básicas de la solución (contenedor), es posible que tenga preguntas o deseos para hacer que alguna funcionalidad sea más bella o efectiva. Seguramente, en primer lugar, recurrirá a las "características" más avanzadas de la solución (contenedor) para esto. Y en esta etapa, puede surgir la siguiente situación: ya conoce bien y confía en la solución elegida, por lo que muchos pueden no pensar en cuán ideológicamente correcto puede ser el uso de uno u otro funcional en la solución, o la transición a otra solución ya es bastante costosa e inapropiada ( por ejemplo, se acerca la fecha límite). Es en esta etapa que puede surgir la situación más peligrosa: la funcionalidad de la solución se utiliza con poco cuidado o, en casos excepcionales, simplemente en la máquina (sin pensar).

¿Quién podría estar interesado en esto?

Este artículo será útil tanto para quienes están familiarizados con la DI como para los principiantes. Para comprender suficiente conocimiento básico sobre qué patrones utiliza DI, el propósito de DI y las funciones que realiza un contenedor de IoC. No se trata de las complejidades de la implementación de Zenject, sino de la aplicación de parte de su funcionalidad. El artículo se basa únicamente en la documentación oficial de Zenject y ejemplos de código, así como en el libro de Mark Siman "Inyección de dependencias en .NET", que es un trabajo exhaustivo clásico sobre el tema de la teoría DI. Todas las citas en este artículo son extractos del libro de Mark Siman. A pesar del hecho de que hablaremos sobre un contenedor específico, el artículo puede ser útil para aquellos que usan otros contenedores.

El propósito de este artículo es mostrar cómo una herramienta cuyo propósito es ayudarlo a implementar DI en su proyecto puede guiarlo en una dirección completamente diferente, empujándolo a cometer errores que vinculan su código, reducen la capacidad de prueba del código y, en general, lo privan de todas las ventajas que pueden brindarle usted DI.

Descargo de responsabilidad : El propósito de este artículo no es criticar a Zenject ni a sus autores. Zenject se puede utilizar para el propósito previsto y servir como una excelente herramienta para implementar DI, siempre que no utilice un conjunto completo de sus funciones, ya que ha definido algunas limitaciones para usted.

Introduccion

Zenject es un contenedor de inyección de dependencia de código abierto destinado a usar el motor de juego Unity3D, que funciona en la mayoría de las plataformas compatibles con Unity3D. Vale la pena señalar que Zenject también se puede usar para aplicaciones C # desarrolladas sin Unity3D. Este contenedor es bastante popular entre los desarrolladores de Unity, está activamente respaldado y desarrollado. Además, Zenject tiene toda la funcionalidad necesaria del contenedor DI.

Usé Zenject en 3 grandes proyectos de Unity, y también me comuniqué con una gran cantidad de desarrolladores que lo usaron. La razón para escribir este artículo son las preguntas frecuentes:

• ¿Usar Zenject es una buena solución?
• ¿Qué le pasa a Zenject?
• ¿Qué dificultades surgen al usar Zenject?

Y también algunos proyectos en los que el uso de Zenject no condujo a la solución de problemas de conectividad de código fuerte y arquitectura fallida, sino que exacerbó la situación.

Veamos por qué los desarrolladores tienen tales preguntas y problemas. Puede responder de la siguiente manera:

Irónicamente, los contenedores DI en sí tienden a ser dependencias estables. ... Cuando decide desarrollar su aplicación en función de un contenedor DI particular, corre el riesgo de limitarse a esta opción durante todo el ciclo de vida de la aplicación.

Vale la pena señalar que con el uso adecuado y limitado del contenedor, cambiar a usar otro contenedor en la aplicación (o negarse a usar el contenedor a favor de la " implementación para los pobres ") es bastante posible y no tomará mucho tiempo. Es cierto que en tal situación, es poco probable que lo necesite.

Antes de comenzar a desmontar la funcionalidad potencialmente peligrosa de Zenject, tiene sentido actualizar superficialmente varios aspectos básicos de DI.

El primer aspecto es el propósito de los contenedores DI. Mark Siman escribe lo siguiente en su libro sobre este tema:

Un contenedor DI es una biblioteca de software que puede automatizar muchas de las tareas que se realizan al ensamblar objetos y administrar su ciclo de vida.

No espere que el contenedor DI convierta mágicamente el código fuertemente acoplado en código débilmente acoplado. Un contenedor puede mejorar la eficiencia del uso de DI, pero el énfasis en la aplicación debe colocarse principalmente en el uso de patrones y trabajar con DI.

El segundo aspecto son los patrones DI . Mark Siman identifica cuatro patrones principales, ordenados por frecuencia y la necesidad de su uso:

1. Implementación del constructor: ¿cómo podemos garantizar que la dependencia requerida siempre estará disponible para la clase que se está desarrollando?
2. Implementación de propiedad: ¿cómo puedo habilitar DI como una opción en la clase si hay un valor predeterminado local adecuado?
3. Implementación del método: ¿cómo puedo inyectar dependencias en una clase si son diferentes para cada operación?
4. Contexto ambiental: ¿cómo podemos hacer que una dependencia esté disponible en cada módulo sin incluir aspectos transversales de la aplicación en cada componente API?

Las preguntas indicadas junto al nombre de los patrones describen completamente su alcance. Al mismo tiempo, el artículo no discutirá la Implementación del Constructor (ya que prácticamente no hay quejas sobre su implementación en Zenject) y el Contexto Ambiental (su implementación no está en el contenedor, pero puede implementarlo fácilmente en función de la funcionalidad existente).
Ahora puede ir directamente a la funcionalidad potencialmente peligrosa de Zenject.

Funcionalidad peligrosa.

Implementar propiedades

Este es el segundo patrón DI más común, después de la implementación del constructor, pero se usa con mucha menos frecuencia. Implementado en Zenject de la siguiente manera:

public class Foo { [Inject] public IBar Bar { get; private set; } } 

Además, Zenject también tiene un concepto como "Inyección de campo". Veamos por qué en todos los Zenject esta funcionalidad es la más peligrosa.

• Se utiliza un atributo para mostrar al contenedor qué campo incrustar. Esta es una solución completamente comprensible, desde el punto de vista de la simplicidad y la lógica de implementación del contenedor en sí. Sin embargo, vemos un atributo (así como un espacio de nombres) en el código de la clase. Es decir, al menos indirectamente, pero la clase comienza a saber de dónde obtiene la dependencia. Además, estamos comenzando a ajustar el código de clase en el contenedor. En otras palabras, ya no podemos negarnos a usar Zenject sin manipular el código de clase.
• El patrón en sí se usa en situaciones en las que la dependencia tiene un valor predeterminado local. Es decir, esta es una dependencia opcional, y si el contenedor no puede proporcionarla, entonces no habrá errores en el proyecto y todo funcionará. Sin embargo, con Zenject, siempre obtienes esta dependencia: la dependencia no se convierte en opcional.
• Dado que la dependencia en este caso no es opcional, comienza a estropear toda la lógica de la implementación del constructor, porque solo las dependencias requeridas deben introducirse allí. Al implementar dependencias no opcionales a través de propiedades, tiene la oportunidad de crear dependencias circulares en el código. No serán tan obvios, porque en Zenject, la implementación del constructor se cumple primero, y luego la implementación de la propiedad, y no recibirá una advertencia del contenedor.
• El uso del contenedor DI implica la implementación del patrón de raíz de composición, sin embargo, el uso del atributo para configurar la implementación de la propiedad lleva al hecho de que configura el código no solo en la raíz de composición, sino también según sea necesario en cada clase.

Fábricas (y MemoryPool)

La documentación de Zenject tiene una sección completa sobre fábricas. Esta funcionalidad se implementa a nivel del contenedor en sí, y también es posible crear sus propias fábricas personalizadas. Echemos un vistazo al primer ejemplo de la documentación:

 public class Enemy { DiContainer Container; public Enemy(DiContainer container) { Container = container; } public void Update() { ... var player = Container.Resolve<Player>(); WalkTowards(player.Position); ... etc. } } 

Ya en este ejemplo hay una violación grave de DI. Pero este es más bien un ejemplo de cómo hacer una fábrica totalmente personalizada. ¿Cuál es el principal problema aquí?

Un contenedor DI puede considerarse erróneamente como un localizador de servicios, pero solo debe usarse como un mecanismo para vincular gráficos de objetos. Si consideramos el contenedor desde este punto de vista, tiene sentido limitar su uso solo a la raíz del diseño. Este enfoque tiene la ventaja importante de que elimina cualquier enlace entre el contenedor y el resto del código de la aplicación.

Veamos cómo funcionan las fábricas "integradas" de Zenject. Hay una interfaz IFactory para esto, cuya implementación nos lleva a la clase PlaceholderFactory:

  public abstract class PlaceholderFactory<TValue> : IPlaceholderFactory { [Inject] void Construct(IProvider provider, InjectContext injectContext) 

En él vemos el parámetro InjectContext que tiene muchos constructores, de la forma:

  public InjectContext(DiContainer container, Type memberType) : this() { Container = container; MemberType = memberType; } 

Y nuevamente, obtenemos la transferencia del contenedor en sí como una dependencia de la clase. Este enfoque es una violación grave de DI y una transformación parcial del contenedor en un Localizador de servicios.
Además, la desventaja de esta solución es que el contenedor se usa para crear dependencias a corto plazo, y solo debe crear dependencias a largo plazo.

Para evitar tales violaciones, los autores del contenedor podrían excluir por completo la posibilidad de pasar el contenedor como una dependencia a todas las clases registradas. No sería difícil implementar esto, dado que todo el contenedor funciona mediante la reflexión y el análisis de los parámetros de métodos y constructores para crear y diseñar el gráfico de los objetos de la aplicación.

Implementación del método

La lógica de la implementación del Método en Zenject es la siguiente: primero, en todas las clases, se implementa el constructor, luego se implementan las propiedades y finalmente se implementa el método. Considere el ejemplo de implementación proporcionado en la documentación:

 public class Foo { [Inject] public Init(IBar bar, Qux qux) { _bar = bar; _qux = qux; } } 

¿Cuáles son las desventajas aquí:

• Puede escribir cualquier número de métodos que se implementarán dentro del marco de una clase. Por lo tanto, como en el caso de la implementación de la propiedad, tenemos la oportunidad de hacer tantas dependencias cíclicas como sea posible.
• Al igual que la implementación de una propiedad, la implementación de un método se implementa mediante un atributo, que asocia su código con el código del contenedor en sí.
• La implementación del método en Zenject se usa solo como una alternativa a los constructores, lo cual es conveniente en el caso de las clases MonoBehavior, pero contradice absolutamente la teoría descrita por Mark Siman. El ejemplo clásico de la implementación canónica del método puede considerarse el uso de fábricas (métodos de fábrica).
• Si hay varios métodos introducidos en la clase, o además del método también hay un constructor, resulta que las dependencias necesarias para la clase se dispersarán en diferentes lugares, lo que interferirá con la imagen como un todo. Es decir, si la clase 1 tiene un constructor, entonces el número de sus parámetros puede mostrar claramente si hay errores de diseño en la clase y si se viola el principio de responsabilidad exclusiva, y si las dependencias se dispersan por varios métodos, por el constructor, o tal vez por un par de propiedades, entonces la imagen no será tan obvia como podría ser.

Se deduce que la presencia de tal implementación de la implementación del método en el contenedor, que contradice la teoría DI, no tiene una sola ventaja. Con una gran advertencia, un plus solo puede considerarse la posibilidad de utilizar el método implementado, como un constructor para MonoBehaviour. Pero este es un momento bastante controvertido, ya que desde el punto de vista de la lógica del contenedor, los patrones DI y el dispositivo de memoria interna Unity3D, todos los objetos MonoBehaviour en su aplicación pueden considerarse administrados por recursos, y en este caso, será mucho más eficiente delegar la administración del ciclo de vida de dichos objetos. no un contenedor DI, sino una clase auxiliar (ya sea Wrapper, ViewModel, Fasade u otra cosa).

Enlaces globales

Esta es una funcionalidad auxiliar bastante conveniente que le permite establecer carpetas globales que pueden vivir independientemente de la transición entre escenas. Puedes leer más en la documentación . Esta funcionalidad es extremadamente conveniente y bastante útil. Vale la pena señalar que no viola los patrones y principios de DI, sin embargo, tiene una implementación fea y obvia. La conclusión es que crea un tipo especial de prefabricado, adjunta un script con la configuración del contenedor (instalador) y lo guarda en una carpeta de proyecto estrictamente definida, sin la capacidad de moverse a ningún lado y sin ningún enlace. La desventaja de esta herramienta radica únicamente en su carácter implícito. Cuando se trata de instaladores normales, todo es bastante simple: tienes un objeto en el escenario, el script del instalador se cuelga de él. Si un nuevo desarrollador llega al proyecto, el instalador se convierte en un excelente punto de inmersión en el proyecto. Basado en un único instalador, un desarrollador puede hacerse una idea de en qué módulos consiste un proyecto y cómo se construye un gráfico de objetos. Pero con el uso de carpetas globales, el instalador en el escenario deja de ser una fuente suficiente de esta información. No hay un solo enlace al enlace global en el código de otros instaladores (presente en las escenas) y, por lo tanto, no ve el gráfico completo de los objetos. Y solo durante el análisis de las clases entiendes que algunos de los ligantes no son suficientes en el instalador en el escenario. Una vez más, haré una reserva de que este inconveniente es puramente cosmético.

Identificadores

La capacidad de establecer un enlace específico para un identificador con el fin de obtener una cierta dependencia de un conjunto de dependencias similares en una clase. Un ejemplo:

 Container.Bind<IFoo>().WithId("foo").To<Foo1>().AsSingle(); Container.Bind<IFoo>().To<Foo2>().AsSingle(); public class Bar1 { [Inject(Id = "foo")] IFoo _foo; } public class Bar2 { [Inject] IFoo _foo; } 

Esta funcionalidad puede ser realmente útil situacionalmente, y es una opción adicional para la implementación de propiedades. Sin embargo, junto con la conveniencia, hereda todos los problemas identificados en el párrafo "Implementando propiedades", agregando aún más coherencia al código al introducir una cierta constante que debe recordar al configurar su código. Si elimina accidentalmente este identificador, puede obtener fácilmente uno que no funciona de la aplicación de trabajo.

Señales e ITickable

Las señales son un análogo del mecanismo del Agregador de eventos integrado en el contenedor. La idea de implementar esta funcionalidad es indudablemente noble, ya que tiene como objetivo reducir el número de conexiones entre objetos que se comunican a través del mecanismo de eventos-suscripciones. Un ejemplo bastante voluminoso se puede encontrar en la documentación , sin embargo, no estará en el artículo, porque la implementación específica no importa.

Soporte para la interfaz ITickable: reemplaza los métodos estándar Update, LateUpdate y FixedUpdate en Unity al delegar las llamadas a los métodos de actualización de objetos con la interfaz ITickable en el contenedor. También hay un ejemplo en la documentación , y su implementación en el contexto del artículo tampoco importa.

El problema de Signals and ITickable no se refiere a aspectos de su implementación, su raíz radica en el uso de efectos secundarios del contenedor. En esencia, el contenedor conoce casi todas las clases y sus instancias dentro del proyecto, pero su responsabilidad es crear un gráfico de objetos y administrar su ciclo de vida. Al agregar mecanismos como Signals, ITickable, etc., agregamos más responsabilidades al contenedor, y cada vez más le adjuntamos el código de la aplicación, convirtiéndolo en la parte exclusiva e irremplazable del código, prácticamente un "objeto divino".

En lugar de salida

Lo más importante acerca de los contenedores es entender que el uso de DI es independiente del uso de un contenedor de DI. Se puede construir una aplicación a partir de muchas clases y módulos poco acoplados, y ninguno de estos módulos debe saber nada sobre el contenedor.

Tenga cuidado al usar soluciones listas para usar (en caja) o pequeños complementos. Úsalos cuidadosamente. De hecho, incluso cosas más grandiosas en las que confía (por ejemplo, motores de juego de la escala de Unity3D) pueden pecar con tales errores teóricos y borrones. Y esto, en última instancia, afectará no el trabajo de la solución que usa, sino la sostenibilidad, el trabajo y la calidad de su producto final. Espero que todos los que hayan leído hasta el final, el artículo les sea útil o, al menos, no se arrepientan del tiempo dedicado a leerlo.