Liaison singleton à plusieurs services dans Ninject

Question

J'ai un problème qui semble très similaire à celui décrit dans http://markmail.org/message/6rlrzkgyx3pspmnf qui est à propos de singleton créant plus d'une instance si vous y accédez en utilisant différents types de services.

J'utilise la dernière version de Ninject 2 pour Compact Framework et la question exacte que je vais avoir est que si je lie la même méthode de fournisseur à:

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

Il semble créer 2 cas de Service si je résous à la fois comme IService et Service.

Cela provoque une exception de dépendance circulaire lors de la résolution du service.

Est-ce intentionnellement ou est-ce un bug?

Answer 1

En V3, il existe enfin une solution pour cela sous la forme new overloads on Bind, voir this related: question.

---

Si vous voulez que le singleton à partager, vous devez changer votre deuxième Bind à:

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

Re références circulaires et de la confusion, etc. En interne l'implicite autolimitation ajoutera une liaison implicite inscription pour le service. Vous devriez publier l'exception.

EDIT: Re votre commentaire. Si vous le faites comme ceci:

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

alors aucune classe auto implicite La liaison est généré lorsque IService se résoudre - il utilise l'existant. - Cet exemple aurait l'ordre correct mais celui ci-dessus est logique en fonction de ma lecture de la source et de la façon dont elle génère les auto-liaisons de classe implicites.

Answer 2

Nous avons utilisé la méthode de Ruben dans notre projet, mais avons trouvé que ce n'était pas intuitif de savoir pourquoi vous reveniez au noyau dans votre liaison. J'ai créé une méthode d'extension et de classe aide (ci-dessous) afin que vous pouvez faire ceci:

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

qui semblait exprimer l'intention plus clairement à moi.

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

Par ailleurs, Ninject 3 allows this syntax:

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

Ou, similaire:

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

Cette dernière approche fonctionne mieux si vous avez de nombreux services, ou si vous découvriez les services dynamiquement au moment de l'exécution (vous pouvez passer directement les arguments params en tant que tableau).