¿Hay un contenedor de instancias alrededor de una clase estática con el propósito de DI y anti patrón?

Question

He creado un pequeño objeto estático para guardar tipos genéricos en Almacenamiento aislado en WP7. Esto funciona de maravilla para proyectos más antiguos, pero algunos de los proyectos nuevos usan DI para administrar la configuración. Soy un fan de DI porque significa que puedo cambiar la configuración en un solo lugar y filtrarla a todas las dependencias.

Mi idea era crear un espacio de nombres llamado Injection y envolver este objeto en una instancia con una interfaz para poder inyectarlo. También me permitiría cambiar el controlador de almacenamiento por uno que requiera una implementación más específica.

¿Es esta práctica común o se trata de un patrón anti?

Como nota, quiero mantener la opción estática ya que no todo el mundo necesita o puede usar DI. Simplemente estoy tratando de habilitar ambos con la menor cantidad de duplicaciones.

Answer 1

Ve esto todo el tiempo. Principalmente es para trabajar con el código heredado que ya está estático o sellado o no implementa ninguna interfaz. Mientras que una clase base en lugar de una interfaz, HttpContextBase es el ejemplo más destacado que se me ocurre.

Como quiera mantener la opción estática, esa es básicamente la situación en la que se encuentra actualmente, así que adelante y hágalo. Sin embargo, no crearía un espacio de nombre Injection, ya que ese nombre dice más sobre la mecánica que el papel que desempeña el objeto.

No escribe exactamente cómo la clase es estática, pero asumo que estamos hablando de una clase estática con métodos estáticos.

Una solución un poco más elegante (si se puede cambiar la clase un poco) es convertir la clase estática en un Singleton. Entonces podría ser estática e implementar la interfaz al mismo tiempo:

public class Foo : IFoo 
{ 
    private readonly static Foo instance = new Foo(); 

    private Foo() { } 

    public static Foo Instance 
    { 
     get { return Foo.instance; } 
    } 

    // IFoo member: 
    public void InterfaceFoo() 
    { 
     Foo.LegacyFoo(); 
    } 

    public static void LegacyFoo() 
    { 
     // Implementation goes here... 
    } 
} 

Creo que la única refactorización necesario para llegar a una solución de este tipo es hacer que la propia clase concreta y que sea implementa la interfaz como un Singleton.

clientes viejos todavía podían acceder a sus métodos invocando Foo.LegacyFoo();

Answer 2

En mi opinión, que dejaría contenedor de inyección de dependencias decidir si es transitoria o Singleton - No sé qué marco se está utilizando ya, pero la mayoría de ellos debería controlar el ciclo de vida de las dependencias -.

Y las aplicaciones de inyección de pre-dependencia pueden mantener una instancia estática de este objeto como parte de una administración de estado de toda la aplicación.