Alternative à HttpContext lors de l'utilisation ninject avec un service WCF hébergé dans employais MSMQ liant

Question

J'ai un service WCF à sens unique en utilisant la liaison MSMQ qui est activé à l'aide de service d'activation de Windows dans IIS 7.0.

Je suis un grand fan sur ninject donc je l'ai utilisé l'extension ninject pour WCF, qui, pour un service WCF HTTP typique serait excellent travail.

Cependant, les services WAS activate il n'y a pas de pipeline HTTP, donc je ne peux pas utiliser InRequestScope lors de la liaison mes types parce System.Web.HttpContext.Current est nulle. Je me bats pour trouver une solution de rechange lors de l'utilisation WAS qui va me donner ce que je veux. attribut mode AspCompatibility ne fonctionne pas dans ce mode soit.

Je pensais que InThreadScope pourrait fonctionner, mais le service est créé dans un thread séparé de ce qu'il est exécuté.

Donc, fondamentalement, je dois l'équivalent du HttpContext pour WCF + Devait-champ mes objets au niveau de la demande. Y at-il un objet statique dans ce monde qui fonctionnerait de la même façon ou quelqu'un d'autre a des idées sur quelque chose que je peux pirater ensemble?

Answer 1

J'ai mis en mes propres extensions WCF pour Ninject 2.0 avant que je savais qu'il y avait un ce sur GitHub. Ma mise en œuvre diffère légèrement, mais je ne viens avec une solution à la portée des objets:

using System;
using Ninject.Activation;

namespace Ninject.Contrib.Wcf {
  /// <summary>
  /// Defines Scope Callbacks for WCF Context.
  /// </summary>
  public class NinjectWcfScopeCallbacks {
    /// <summary>
    /// Defines WCF Context scope.
    /// </summary>
    public static readonly Func<IContext, object> WcfContext =
      ctx => (System.ServiceModel.OperationContext.Current != null
                ? System.ServiceModel.OperationContext.Current.
                    InstanceContext.
                    Extensions.Find<NinjectInstanceContext>()
                : null);

    /// <summary>
    /// Defines WCF Web Context scope.
    /// </summary>
    public static readonly Func<IContext, object> WcfWebContext = 
               ctx => System.ServiceModel.Web.WebOperationContext.Current;
  }
}

Pour être complet, voici comment j'utiliser la fonction de rappel défini ci-dessus:

Bind<IHelloWorldService>()
        .To<HelloWorldService>()
        .InScope(NinjectWcfScopeCallbacks.WcfWebContext);

n'ont pas accueilli les services WCF dans WAS, donc je ne sais si vous utilisez le WcfWebContext ou WcfContext défini ci-dessus, mais vous pouvez essayer « em et voir. Si fonctionne WebOperationContext, alors vous êtes tous ensemble. Dans le cas contraire, je trouve les choses sont un peu plus compliqué. Vous remarquerez que l'extrait de code ci-dessus utilise une classe NinjectInstanceContext qui est attaché à la OperationContext. C'est une classe que j'ai écrit qui utilise le mécanisme « cache et recueillir » de Ninject 2.0 qui permet aux objets d'être disposés de manière déterministe. En fait, la classe est IExtension<InstanceContext> outils qui est une construction WCF pour attacher presque tout à l'OperationContext. Cette classe également mettre en œuvre l'interface INotifyWhenDisposed de Ninject qui est ce qui fournit un soutien pour l'élimination déterministe. Voici ce que la définition de classe ressemble à:

  /// <summary>
  /// Defines a custom WCF InstanceContext extension that resolves service instances
  /// using Ninject.  
  /// <remarks>
  /// The custom InstanceContext extension provides support for deterministic disposal
  /// of injected dependencies and service instances themselves by being hook into 
  /// Ninject's "cache and collect" mechanism (new in Ninject 2.0) for object life cycle 
  /// management.  This allows binding object instances to the lifetime of a WCF context
  /// and having them deterministically deactivated and disposed.
  /// </remarks>
  /// </summary>
  public class NinjectInstanceContext : 
                IExtension<InstanceContext>, INotifyWhenDisposed {
  }

Le reste de mon extension WCF pour Ninject est le même que le un sur GitHub. Ce qui se passe essentiellement est qu'un fournisseur d'instance est créé qui est branché dans la chaîne WCF « d'activation » - Je ne suis pas en utilisant leur terminologie spécifique, comment je comprends les choses. Donc, l'idée est que votre fournisseur d'instance est censée fournir des instances de la classe de service WCF demandée. Donc, voici où nous utilisons Ninject pour produire l'instance de service. Ce faisant, nous pouvons aussi activer et injecter des dépendances. Qu'est-ce que le fournisseur de l'instance fait dans ma mise en œuvre est envelopper le noyau Ninject dans une instance si NinjectInstanceContext et l'attacher à la OperationContext. La création du service est alors déléguée à cette extension WCF. Lorsque le fournisseur d'instance est dit de libérer un service, l'NinjectInstanceContext qui a été attaché à l'OperationContext est disposé que par la mise en œuvre INotifyWhenDisposed provoque l'élimination déterministe du service (et éventuellement ses dépendances).

Hope cette discussion aide. Je vais voir si je peux obtenir un code plus concret affiché ici si vous êtes intéressé.

Answer 2

Je suis sûr OperationContext est ce que vous cherchez