¿Contenedor DI, de fábrica o nuevo para objetos efímeros?

Question

Cuando se trata de objetos que requieren datos conocidos solo en tiempo de ejecución, como un nombre de usuario y contraseña, ¿dónde debería ocurrir la instanciación de objetos: utilizando nuevo, en una fábrica o en un contenedor DI?

Por ejemplo, tan sólo pudiera new un objeto una vez que tenga los datos:

UserCredentials creds = 
    new UserCredentials(dialog.getUsername(), dialog.getPassword()); 

O, podría usar una fábrica:

UserCredentials creds = 
    CredentialsFactory.create(dialog.getUsername(), dialog.getPassword()); 

O, podría usar un proveedor dentro de una Contenedor DI (que en este caso sería esencialmente una fábrica impulsada por parámetros). [Código de muestra omitido.]

Parece incorrecto utilizar el contenedor DI para algo tan simple pero también parece incorrecto no usarlo al máximo.

Answer 1

Como siempre, depende, pero como regla general, una fábrica estática como su segunda opción rara vez es una buena idea.

new La creación de un objeto UserCredential parece una opción justa porque la clase UserCredentials parece una clase concreta y autónoma que puede crearse una instancia completa con todas sus invariantes del nombre de usuario y la contraseña.

En otros casos, el tipo que desea crear puede representar una abstracción en sí mismo. Si este es el caso, no puede usar la palabra clave new, sino que debe usar Abstract Factory.

El uso de Abstract Factory suele ser muy valioso porque le permite componer una instancia a partir de una combinación de valores de tiempo de ejecución y otras dependencias. Consulte here para obtener más información.

El uso de una fábrica abstracta también ayuda con unidad de prueba, ya que simplemente puede probar que el valor de retorno o de estado final o lo que usted quiere está relacionada con la producción de la fábrica abstracta - para el que puede suministrar fácilmente un Prueba doble porque es ... abstracto.

Answer 2

Para mí, uso DI para crear un acoplamiento más flexible entre los objetos. Si las dependencias de objeto se ven muy afectadas al crear un objeto utilizando new, entonces no veo por qué no podría usar DI o crear objetos de retransmisión en una fábrica. Esto te da más control y mantiene tus clases juntas.

Realmente depende de cuándo y dónde necesitará este objeto y si habrá dependencias innecesarias como resultado.

Answer 3

Si ya tiene un contenedor DI configurado para su aplicación, utilice este enfoque. Si no, usa un método de fábrica.

Answer 4

El blog de pruebas de google tiene a post which tries to answer this question. La idea básica es que puede clasificar cada una de sus clases como "nueva" o "inyectable", y que está bien simplemente "actualizar" las nuevas.

distingo 2 categorías principales de "newables":

• valores como int, string, DateTime, etcétera.
• entidades como Customer, Order, Employee, etcétera. Creo que su clase UserCredentials cae bajo este título.

Es importante darse cuenta de que newables pueden tener (comprobable) comportamiento. Si comete el error de pensar que los nuevos no deberían tener ningún comportamiento o pruebas unitarias, terminará con el anemic domain model antipatrón.

Un efecto secundario de tener "nuevas opciones" con el comportamiento es que este comportamiento no puede abstraerse en las pruebas unitarias de sus inyectables. Esto esta bien; es normal tener un fuerte acoplamiento entre su modelo de dominio y el resto de su aplicación.

Además, los nuevos están autorizados a saber sobre los inyectables, pero solo cooperan con ellos de forma transitoria. Por ejemplo, UserCredentials no debe tomar un IUserDatabase como un argumento de constructor. En cambio, puede haber un método UserCredentials.Verify(IUserDatabase).

editar: Actualmente no estoy tan seguro de lo que escribí arriba. Las entidades también se pueden construir a través de fábricas (inyectables) en lugar de llamar a su constructor directamente. La implementación de fábrica puede inyectar cosas en la entidad.