2010-11-03 7 views
6

Tengo una pregunta sobre el patrón de inyección de dependencia. Mi pregunta es ... Si uso la inyección de constructor, inyectando las dependencias para mi clase, lo que obtengo es un constructor "grande" con muchos params. ¿Qué pasa si es decir? No uso algunos de los params en algunos métodos? Es decir. Tengo un servicio que expone muchos métodos. Y un constructor con 10 parámetros (todas las dependencias). Pero no todos los métodos usan todas las dependencias. Algún método usará solo una dependencia, otro usará 3 dependencias. Pero el contenedor DI los resolverá todos incluso si no se usan.Pregunta de inyección de dependencias

Para mí, esto es una penalización de rendimiento al utilizar el contenedor DI. ¿Es esto cierto?

Respuesta

0

También puede ocultar algunas dependencias que aún no se necesitan detrás de los proveedores perezosa. Por ejemplo:

public DataSourceProvider implements Provider<DataSource> { 

    public DataSource get() { 
     return lazyGetDataSource(); 
    } 

} 

El Provider interface es parte de javax.inject paquete.

0

En realidad no puede saber qué métodos se utilizan en tiempo de ejecución cuando construye su contenedor DI. Tendría que lidiar con esa penalización de rendimiento o si sabe que hay muchos casos en los que se usan solo unas pocas dependencias, puede dividir su contenedor en varios contenedores pequeños que tienen menos dependencias que se inyectan.

7

Parece que su clase está haciendo demasiado, que no cumple con la S en SOLID (Principio de responsabilidad única), tal vez podría dividir la clase en múltiples clases más pequeñas con menos dependencias. El hecho de que no todas las dependencias sean utilizadas por todos los métodos sugiere esto.

1

Normalmente, la penalización de rendimiento de inyectar muchas dependencias es baja, pero depende del marco que elija. Algunos compilarán métodos para esto sobre la marcha. Tendrás que probar esto. Muchas dependencias indican que su clase está haciendo demasiado (como dijo Ruben), por lo que es posible que desee echar un vistazo a eso. Si la creación de una instancia de dependencia que a menudo no utiliza causa problemas de rendimiento, es posible que desee introducir una fábrica como dependencia. Descubrí que el uso de fábricas puede resolver muchos problemas relacionados con el uso de marcos de inyección de dependencias.

// Constructor 
public Consumer(IContextFactory contextFactory) 
{ 
    this.contextFactory = contextFactory; 
} 

public void DoSomething() 
{ 
    var context = this.contextFactory.CreateNew(); 
    try 
    { 
     // use context here 

     context.Commit(); 
    } 
    finally 
    { 
     context.Dispose(); 
    } 
} 
0

Como Rube Dice probabily debe revisar el diseño del te de la clase que se adhieren a los principios sólidos.

De todos modos si no es realmente necesario, estoy acostumbrado a buscar la dependencia del constructor de propiedades en lugar del constructor. Significa que puedes crear una propiedad para cada dependencia que necesites. Eso también ayuda a probar la clase porque puede inyectar solo la dependencia que necesita en el contexto de la prueba que está haciendo en lugar de anular toda la dependencia, incluso si no la necesita

+1

El estado mutable debe evitarse en absoluto costos. –

+0

Estoy de acuerdo. En mi respuesta, estoy de acuerdo con Rube, quien dijo que probabilmente debería revisar el diseño de su clase. Mi segundo comentario fue simplemente práctico :-) –

Cuestiones relacionadas