Альтернативой HttpContext при использовании NInject со службой WCF, размещенной в, было использование привязки MSMQ
-
20-09-2019 - |
Вопрос
У меня есть односторонняя служба WCF, использующая привязку MSMQ, которая активируется с помощью службы активации Windows в IIS 7.0.
Я большой поклонник NInject, поэтому я использую расширение NInject для WCF, которое отлично подойдет для типичного HTTP-сервиса WCF.
Однако в службах WAS activate отсутствует HTTP-конвейер, поэтому я не могу использовать InRequestScope при привязке моих типов, потому что System.Web.HttpContext.Current имеет значение null.Я изо всех сил пытаюсь найти альтернативу при использовании WAS, которая даст мне то, что я хочу.Атрибут режима совместимости также не работает в этом режиме.
Я думал, что InThreadScope может сработать, но служба создается в отдельном потоке, отличном от того, в котором она выполняется.
Итак, в принципе, мне нужен эквивалент HttpContext для WCF +, чтобы охватить мои объекты на уровне запроса.Есть ли в этом мире какой-нибудь статический объект, который работал бы точно так же, или у кого-нибудь еще есть какие-нибудь идеи о том, что я могу взломать вместе?
Решение
Я внедрил свои собственные расширения WCF для Ninject 2.0 еще до того, как узнал, что существует это смотрите на 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's 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 такая же, как один на github.Что в основном происходит, так это то, что создается поставщик экземпляра, который подключается к цепочке "активации" WCF - я не использую их специфическую терминологию, просто то, как я понимаю вещи.Итак, идея заключается в том, что ваш поставщик экземпляров должен предоставлять экземпляры запрашиваемого класса обслуживания WCF.Итак, вот где мы используем Ninject для создания экземпляра сервиса.Поступая таким образом, мы также можем активировать и внедрять любые зависимости.Что делает поставщик экземпляра в моей реализации, так это завершает ядро Ninject в экземпляре, если NinjectInstanceContext
и прикрепите его к OperationContext
.Затем создание сервиса делегируется этому расширению WCF.Когда поставщику экземпляра предлагается выпустить службу, NinjectInstanceContext
, который был прикреплен к OperationContext, удален, который посредством реализации INotifyWhenDisposed
вызывает детерминированное удаление сервиса (и, возможно, его зависимостей).
Надеюсь, это обсуждение поможет.Я посмотрю, смогу ли я разместить здесь более конкретный код, если вам интересно.
Другие советы
я уверен OperationContext
это то, что ты ищешь