Альтернатива HttpContext при использовании NInject с сервисом WCF Хостинг в WAS с использованием привязки MSMQ

Question

У меня есть односторонняя служба WCF, использующая привязку MSMQ, которая активируется с помощью службы активации Windows в IIS 7.0.

Я большой поклонник NInject, поэтому я использовал расширение NInject для WCF, которое для типичной службы HTTP WCF будет работать отлично.

Однако в WAS активировать службы нет HTTP-конвейера, поэтому я не могу использовать InRequestScope при привязке своих типов, потому что System.Web.HttpContext.Current имеет значение null. Я изо всех сил пытаюсь найти альтернативу при использовании WAS, который даст мне то, что я хочу. Атрибут режима AspCompatibility также не работает в этом режиме.

Я думал InThreadScope может работать, но служба создается в отдельном потоке, чем то, что он выполнен в.

Поэтому в основном мне нужно эквивалент в HttpContext для WCF + WAS в рамках своих объектов на уровень запроса. Есть ли какой-то статический объект в этом мире, который будет работать одинаково или кто-нибудь еще имеет какие-то идеи о чем-то, что я могу взломать вместе?

Answer 1

Я реализовал свои собственные расширения WCF для Ninject 2.0, прежде чем я знал, что там было this на GitHub. Моя реализация немного отличается, но я придумал решение для обзорных объектов:

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

Для полноты картины, это то, как я использую функцию обратного вызова, определенный выше:

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

не организовано WCF услуг в WAS, поэтому не уверен, что вы использовали бы указанные выше WcfWebContext или WcfContext, но вы можете попробовать их и посмотреть. Если WebOperationContext работает, тогда вы все настроены. В противном случае я обнаружил, что вещи немного сложнее. Вы заметите, что фрагмент кода выше использует класс NinjectInstanceContext, который подключен к OperationContext. Это класс, который я написал, который использует механизм «кэширования и сбора» Ninject 2.0, который позволяет детерминировать объекты. В принципе, класс реализует IExtension<InstanceContext>, который представляет собой конструкцию WCF для прикрепления почти ничего к OperationContext. Этот класс также реализует интерфейс Ninject INotifyWhenDisposed, который обеспечивает поддержку детерминированного удаления. Вот то, что определение класса выглядит следующим образом:

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

Остальная часть моего расширения WCF для Ninject является такой же, как one на GitHub. Что в основном происходит, так это то, что создается поставщик экземпляров, который подключен к цепочке активации WCF - я не использую их специфическую терминологию, просто как я понимаю вещи. Итак, идея заключается в том, что поставщик вашего экземпляра должен предоставлять экземпляры запрашиваемого класса службы WCF. Итак, вот где мы используем Ninject для создания экземпляра службы. Поступая таким образом, мы также можем активировать и вводить любые зависимости. То, что поставщик экземпляра делает в моей реализации, завершает ядро ​​Ninject в экземпляре, если NinjectInstanceContext и прикрепляет его к OperationContext. Затем создание этой службы делегируется этому расширению WCF. Когда поставщику экземпляра сообщается о выпуске услуги, удаляется , который был прикреплен к OperationContext, который посредством реализации INotifyWhenDisposed вызывает детерминированное удаление услуги (и, возможно, ее зависимостей).

Надеюсь, что это обсуждение поможет.Я посмотрю, могу ли я получить более конкретный код, размещенный здесь, если вам интересно.

Answer 2

я уверен, что OperationContext является то, что вы ищете