Vinculando singleton a servicios múltiples en Ninject

Question

Tengo un problema que parece muy similar al descrito en http://markmail.org/message/6rlrzkgyx3pspmnf, que trata de que el singleton realmente cree más de una instancia si está accediendo a él utilizando diferentes tipos de servicio.

estoy usando la última versión de Ninject 2 para Compact Framework y el problema exacto que estoy teniendo es que si Ato el mismo método que el proveedor:

Func<Service> serviceCreator =() => new Service(false); 
kernel.Bind<IService>().ToMethod(serviceCreator).InSingletonScope(); 
kernel.Bind<Service>().ToMethod(serviceCreator).InSingletonScope(); 

Parece ser la creación de 2 casos de Servicio si resuelvo ambos como servicio de IServicio y Servicio.

Esto provoca una excepción de dependencia circular al resolver el servicio.

¿Es esto por diseño, o es un error?

Answer 1

En V3, finalmente hay una solución para esto en la forma de new overloads on Bind, vea this related: question.

---

Si desea que el producto único a ser compartida, tiene que cambiar su segundo Bind a:

kernel.Bind<Service>().ToMethod(()=>kernel.Get<IService>()).InSingletonScope(); 

Re referencias circulares y confusión etc. Internamente, la implícita autovinculantes agregará una unión implícita registro para el Servicio. Deberías publicar la excepción.

EDIT: Re su comentario. Si lo haces de esta manera:

Func<Service> serviceCreator =() => new Service(false); 
kernel.Bind<Service>().ToMethod(serviceCreator).InSingletonScope(); 
kernel.Bind<IService>().ToMethod(()=>kernel.Get<Service>()).InSingletonScope(); 

Entonces hay implícita Clase unión libre se genera cuando se resuelva IService - que utiliza la ya existente.

There was another Q here on SO in recent weeks someone was doing this type of thing but was running into an issue with IInitializable - ese ejemplo tendría el orden correcto, pero el anterior tiene sentido en función de mi lectura de la fuente y la forma en que genera las auto-vinculaciones de clases implícitas.

Answer 2

Utilizamos el método de Ruben en nuestro proyecto, pero descubrimos que no era intuitivo por qué volvíamos al Kernel en su encuadernación. He creado una clase de método de extensión y ayudante (abajo) para que pueda hacer esto:

kernel.Bind<IService>().ToExisting().Singleton<Service>(); 

que parecía expresar la intención más clara para mí.

public static class DIExtensions 
{ 
    public static ToExistingSingletonSyntax<T> ToExisting<T>(this IBindingToSyntax<T> binding) 
    { 
     return new ToExistingSingletonSyntax<T>(binding); 
    } 
} 

// Had to create this intermediate class because we have two type parameters -- the interface and the implementation, 
// but we want the compiler to infer the interface type and we supply the implementation type. C# can't do that. 
public class ToExistingSingletonSyntax<T> 
{ 
    internal ToExistingSingletonSyntax(IBindingToSyntax<T> binding) 
    { 
     _binding = binding; 
    } 

    public IBindingNamedWithOrOnSyntax<T> Singleton<TImplementation>() where TImplementation : T 
    { 
     return _binding.ToMethod(ctx => ctx.Kernel.Get<TImplementation>()).InSingletonScope(); 
    } 


    private IBindingToSyntax<T> _binding; 
} 

Answer 3

Por cierto, Ninject 3 allows this syntax:

kernel.Bind<IService, Service>().ToMethod(serviceCreator).InSingletonScope(); 

O, de manera similar:

kernel.Bind(typeof(IService), typeof(Service)).ToMethod(serviceCreator).InSingletonScope(); 

Este último enfoque funciona mejor si tiene muchos servicios, o si usted descubrió los servicios dinámicamente en tiempo de ejecución (puede pasar los argumentos de estilo params como una matriz directamente).