Alternativa a HttpContext cuando se utiliza ninject con un servicio WCF Alojado en unión estaba utilizando MSMQ

Question

Tengo un servicio de WCF una forma utilizando la unión de MSMQ que se activa mediante el servicio de activación de Windows en IIS 7.0.

Soy un gran fan de ninject así que he estado usando la extensión ninject de WCF, que para un típico servicio HTTP de WCF trabajaría grande.

Sin embargo, en Activar servicios de WAS no hay canal de HTTP, por lo que no se puede utilizar cuando se une InRequestScope mis tipos System.Web.HttpContext.Current porque es nulo. Estoy luchando para encontrar una alternativa al utilizar fue que me dará lo que quiero. AspCompatibility atributo de modo no funciona en este modo tampoco.

pensé InThreadScope podría funcionar, pero el servicio se crea en un hilo separado de lo que se ejecuta en.

Así que, básicamente necesito el equivalente a la del HttpContext para WCF + debía alcance mis objetos en el nivel de solicitud. ¿Hay algún objeto estático en este mundo que funcionaría de la misma manera o alguien más tiene alguna idea sobre algo que pueda piratear juntos?

Answer 1

He implementado mis propias extensiones de WCF para Ninject 2.0 antes de que yo sabía que era un este arriba en gitHub. Mi aplicación es ligeramente diferente, pero yo no llegar a una solución para la determinación del alcance objetos:

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;
  }
}

Para completar, esta es la forma en que utilizo la devolución de llamada definido anteriormente:

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

servicios WCF

El No se han alojado en WAS, así que no sé si tendrá que utilizar el WcfWebContext o WcfContext definido anteriormente, pero se puede tratar 'em hacia fuera y ver. Si WebOperationContext funciona, entonces ya está todo listo. De lo contrario, encontré las cosas son un poco más complicado. Se habrá dado cuenta el fragmento de código anterior utiliza una clase NinjectInstanceContext que se adjunta a la OperationContext. Esta es una clase que escribí que utiliza "caché y recoger" de Ninject 2.0 mecanismo que permite que los objetos a ser eliminados de forma determinista. Básicamente, la clase es implementos IExtension<InstanceContext> que es un WCF construir para unir casi cualquier cosa a la OperationContext. Esta clase también implementa la interfaz INotifyWhenDisposed de Ninject que es lo que proporciona soporte para la eliminación determinista. Esto es lo que la definición de clase se ve así:

  /// <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 {
  }

El resto de mi extensión WCF para Ninject es el mismo que el uno en github. Lo que pasa es que, básicamente, un proveedor de instancia se crea que se conecta a la cadena de WCF "activación" - no estoy usando su terminología específica, tal como entiendo las cosas. Por lo tanto, la idea es que el proveedor de ejemplo se supone que debe suministrar los casos de que se solicita la clase de servicio WCF. Por lo tanto, aquí es donde utilizamos Ninject para producir la instancia de servicio. Al hacerlo, también podemos activar e inyectar las dependencias. Lo que el proveedor de instancias hace en mi aplicación es envolver el núcleo Ninject en una instancia si NinjectInstanceContext y adjuntarlo a la OperationContext. La creación del servicio es entonces delegada a esta extensión WCF. Cuando el proveedor de instancias se le dice que lanzará un servicio, el NinjectInstanceContext que se adjuntó a la OperationContext el cual está dispuesto a través de la implementación de INotifyWhenDisposed provoca la eliminación determinista del servicio (y, potencialmente, sus dependencias).

Espero que esto ayuda a la discusión. Voy a ver si puedo conseguir algo más de código concreta publicado aquí si está interesado.

Answer 2

Estoy seguro OperationContext es lo que estás buscando