¿Cómo se determina qué clases se deben construir a través de un contenedor de IOC y cuáles no? He trabajado en proyectos con ambos extremos y parece que las interfaces solo deberían usarse cuando las clases especifican una tecnología específica, como el registro o el acceso a los datos.¿Qué debería construirse a través de un contenedor de IOC?
¿Dónde se traza la línea entre los dos?
No dibujo ninguna línea, mientras más, mejor.
Lo que sucede es que cuanto más puedes dividir tu API en unidades pequeñas, cuanto más te acercas al Single Responsibility Principle, porque todo lo que se esconde detrás de una interfaz tendrá una tendencia a hacer una sola cosa, y hacerlo bien.
Al inyectar interfaces en la implementación que implementan nuevas interfaces que se inyectan en otros tipos, etc. termina con una estructura muy flexible donde puede variar detalles de implementación en casi cualquier nivel, y cada colaborador es bastante simple en sí mismo.
Con un buen Contenedor DI y algunas convenciones sensatas, el Contenedor DI se encargará automáticamente de la mayoría de los cables por usted, por lo que la configuración no tiene que ser extrema.
Francamente, es difícil creer que un consejo como este sea serio. Totalmente contradice la intención detrás del artículo original sobre DI de Martin Fowler. Además, la implementación de una clase ya "se esconde detrás de una interfaz": ¡la interfaz pública de la clase en sí! Quiero decir, una Interfaz Separada no es necesaria para eso. (¿O quiso decir "interfaz" en su significado general?) En la mayoría de los casos, simplemente no necesita "variar los detalles de implementación" a través de la configuración; hacerlo de forma predeterminada es un sobrediseño y contradice el verdadero espíritu de DI. –
@Rogerio: El consejo es serio, y he estado usando este principio con gran éxito durante años. Si bien respeto a Fowler, no tenemos que tomar todas sus palabras como escritura. Haga una búsqueda en la web y descubra qué piensa la comunidad .NET de vanguardia sobre las opiniones de Fowler y del Tío Bob sobre DI. Puedes cambiar de opinión, entonces. –
@Mark: bien, no es necesario tomar cada palabra "como escritura", pero el principio fundamental aquí, que es común tanto para DI como para el patrón "Localizador de servicios", es "separar la configuración del uso". OMI, cuando las personas usan DI (o ServiceLocator) sin una necesidad real de esa configuración, están abusando de ella. Y tal abuso, al igual que el abuso de los patrones de GoF (lo que sucede mucho), causa daños graves en proyectos reales, al aumentar los costos de desarrollo y mantenimiento sin aportar ningún beneficio tangible.Eso es lo que me preocupa cuando veo consejos "radicales" como este ("cuanto más, mejor"). –
Las clases que se crearán instancias del contenedor DI (suponiendo que se utilice) deberían ser las que implementan un Separated Interface, y que deben elegirse en tiempo de ejecución según el entorno de ejecución.
Puede preguntar: ¿qué clases deberían implementar una interfaz separada , y cuáles no? Existen básicamente dos razones para crear una nueva interfaz independiente:
Para referencia, véase: http://martinfowler.com/articles/injection.html#SeparatingConfigurationFromUse
DI. Todo. Siempre. Porque. – Aaronaught