Alternativa a HttpContext al usar NInject con un servicio WCF alojado en WAS utilizando enlace MSMQ

Question

Tengo un servicio WCF de una vía que usa el enlace MSMQ que se activa con el servicio de activación de Windows en IIS 7.0.

Soy un gran admirador de NInject, así que he estado usando la extensión NInject para WCF, que para un servicio HTTP WCF típico funcionaría muy bien.

Sin embargo, en los servicios de activación de WAS no hay una conexión HTTP, por lo que no puedo usar InRequestScope al vincular mis tipos porque System.Web.HttpContext.Current es nulo. Estoy luchando por encontrar una alternativa cuando uso WAS que me dará lo que quiero. El atributo del modo AspCompatibility tampoco funciona en este modo.

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 funcione de la misma manera o alguien más tiene alguna idea sobre algo que pueda hackear juntos?

Answer 1

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

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, así es como yo uso la devolución de llamada definido anteriormente:

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

El no han alojado WCF servicios en WAS, por lo que no estoy seguro de si usaría el WcfWebContext o el WcfContext definidos anteriormente, pero puede probarlos y verlos. Si WebOperationContext funciona, entonces ya está todo listo. De lo contrario, descubrí que las cosas son un poco más complicadas. Notará que el fragmento de código anterior usa una clase NinjectInstanceContext que está adjuntada al OperationContext. Esta es una clase que escribí que usa el mecanismo de "caché y recolección" de Ninject 2.0 que permite eliminar los objetos de forma determinista. Básicamente, la clase implementa IExtension<InstanceContext> que es una construcción WCF para adjuntar casi cualquier cosa al 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 se ve como la definición de clase:

/// <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 one en github. Lo que básicamente sucede es que se crea un proveedor de instancias que está conectado a la cadena de "activación" de WCF. No estoy usando su terminología específica, solo cómo entiendo las cosas. Entonces, la idea es que su proveedor de instancia supuestamente proporcione instancias de la clase de servicio WCF solicitada. Entonces, aquí es donde usamos Ninject para producir la instancia de servicio. Al hacerlo, también podemos activar e inyectar cualquier dependencia. Lo que hace el proveedor de instancias en mi implementación es resumir el núcleo de Ninject en una instancia si es NinjectInstanceContext y adjuntarlo al OperationContext. La creación del servicio se delega a esta extensión de WCF. Cuando se le dice al proveedor de la instancia que libere un servicio, se elimina el NinjectInstanceContext que se adjuntó a OperationContext, que a través de la implementación de INotifyWhenDisposed provoca la eliminación determinista del servicio (y posiblemente sus dependencias).

Espero que esta discusión ayude.Veré si puedo obtener un código más concreto publicado aquí si estás interesado.

Answer 2

Estoy seguro OperationContext es lo que estás buscando