Ответ 1
Я реализовал свои собственные расширения WCF для Ninject 2.0, прежде чем понял, что на github есть this. Моя реализация немного отличается, но я придумал решение для объектов с областью видимости:
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);
В WAS не размещены службы WCF, поэтому не уверены, что вы использовали бы описанные выше 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 "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 в экземпляре if NinjectInstanceContext и прикрепляет его к OperationContext. Затем создание этой службы делегируется этому расширению WCF. Когда поставщику экземпляра сообщается о выпуске службы, удаляется NinjectInstanceContext, который был присоединен к OperationContext, который посредством реализации INotifyWhenDisposed вызывает детерминированное удаление службы (и, возможно, ее зависимостей).
Надеюсь, что это обсуждение поможет. Я посмотрю, могу ли я получить более конкретный код, размещенный здесь, если вы заинтересованы.