2009-11-05 15 views
30

Tengo relativamente poca experiencia en Dependency Injection, y me gustaría aprender algunas de las mejores prácticas y antipatrones para usar y evitar, respectivamente, cuando uso DI.Prácticas recomendadas de inyección de dependencias y antipatrones

+2

No creo que el "idioma-agnóstico" ayude aquí: diferentes idiomas dictan enfoques radicalmente diferentes: realmente no querría hacer lo mismo en C++ como, digamos, Ruby. –

+2

Entonces, ¿valdría la pena hacer preguntas separadas por idioma?Aún así, me imagino que hay suficientes patrones generales, por lo que una pregunta genérica está en orden. – ripper234

+0

Animo a todos los interesados ​​en contribuir con esta pregunta a que revisen los temas [de inyección de dependencia] (http://stackoverflow.com/documentation/dependency-injection/topics) en su lugar. – dimo414

Respuesta

1

He encontrado que cuando veo una violación del Law of Demeter es una pista de que podría querer una inyección de dependencia.

Por ejemplo:

void doit() 
{ 
    i += object.anotherobject.addvalue; //violation of Law of Demeter 
} 

insinúa que a veces puede ser que quiera inyectar a la dependencia anotherobject.

+0

Parece un poco arbitrario ... –

+2

Esto tiene algún sentido, aunque es un pequeño salto, y está incompleto. Si encuentra una violación de la ley de demeter, encuentra la oportunidad de elegir el resumen. Cada vez que abstrae, tiene la oportunidad de elegir inyectar la dependencia en lugar de crearla usted mismo. Entonces este es un indicador, pero solo justo. Es posible que existan más oportunidades de abstracción que solo esto, y podría ser útil evitar la DI en lugares donde cuesta más implementar de lo que posiblemente podría obtenerse de ella. Aún así, +1 sin embargo. –

0

Mi regla básica sobre cuándo usar DI es que voy a inyectar entre capas, así que entre mi controlador y el dao sería una capa, por lo que puedo inyectar, por lo que si quiero simular una capa que pueda.

Creo que usar DI dentro de la misma capa no es una buena idea, principalmente porque la capa debe estar estrechamente unida, ya que están relacionadas, a menos que tenga una historia del usuario que la haga útil.

Por ejemplo, si su DAO puede estar en computadoras separadas, entonces puede necesitar pretender que son una capa, pero use DI para realmente cambiar entre todas las máquinas en una misma máquina. Entonces el desarrollador puede hacer todo en una máquina y debería funcionar en máquinas separadas.

Pero, a menos que haya alguna necesidad apremiante, creo que DI dentro de la misma capa es una complicación innecesaria.

+2

Bien utilizando la inyección de dependencia dentro de una capa, volverá a utilizar las instancias de componentes existentes, conservando los recursos. También diría que está fomentando buenos hábitos de programación forzando un diseño modular. –

+0

Acabo de ver que se está volviendo más complicado de lo que debe ser, pero eso depende de lo que hay en la capa. Tiendo a hacerlo entre capas, pero es por eso que expliqué por qué hacerlo entre capas puede ser útil, pero no es algo que pueda sugerir. –

3

En mi opinión, el libro de Dhanji Prasanna Dependency Injection es una lectura obligada para los diseñadores de software, tanto principiantes como expertos. Trata directamente con sus preguntas DI.

+4

Otro gran libro es [Dependency Injection en .NET de Mark Seemann] (http://www.amazon.com/Dependency-Injection-NET-Mark-Seemann/dp/1935182501). – Steven

8

Realmente disfruté este artículo con respecto a DI, ya que está dirigido a personas que no tienen mucha experiencia de DI, o ni siquiera saben de qué se trata.

https://mtaulty.com/2009/08/10/m_11554/

¿Cuál es la unidad?

It’s a “dependency injection container”. 

Ahora, en ese momento un montón de gente leer esta dirá “Sí, sabemos y ya estamos usando por razones A, B, C o hemos optado por no utilizar que por razones X, y, Z”y me imagino un montón de otras personas podrían decir;

“Huh? What’s a dependency injection container?” 

Este post es para las últimas personas - no está destinado a ser exhaustiva, sino es de esperar que no es completamente inútil ya sea :-)

3

Hay una sección de las mejores prácticas en Guice de user's guide.

Cuestiones relacionadas