Mit Einfachen Injektor mit SignalR

Werfen möchte, meine 2 cents in hier mit den anderen Antworten, die hilfreich sein kann bei der Suche nach Ihrem eigenen Weg mit dependency injection in SignalR, entweder mit SimpleInjector oder anderen IoC.

Mit @Steven ' s Antwort

Wenn Sie sich entscheiden, zu verwenden, Steven, Antwort, stellen Sie sicher, Sie registrieren Ihre hub-Routen vor, die Sie verfassen, die Wurzel. Die SignalRRouteExtensions.MapHubs Erweiterung Methode (ein.k.ein. routes.MapHubs()) rufen Register(Type, Func<object>) auf die GlobalHost.DependencyResolver wenn die Zuordnung der hub-Routen, so dass, wenn Sie die swap - DefaultDependencyResolver mit Steven SimpleInjectorResolver vor den Routen zugeordnet sind, führen Sie in seine NotSupportedException.

Mit @Nathanael Marchands Antwort

Dies ist mein Favorit. Warum?

1. Weniger code als die SimpleInjectorDependencyResolver.
2. Keine Notwendigkeit, ersetzen Sie die DefaultDependencyResolver (ein.k.ein. GlobalHost.DependencyResolver), das bedeutet noch weniger code.
3. Können Sie Komponieren die Wurzel entweder vor oder nach der mapping-hub-Strecken, da Sie nicht zu ersetzen, die DefaultDependencyResolver, es wird "einfach funktionieren".

Wie Nathanael sagte aber, dies ist nur, wenn Sie kümmern sich um die Abhängigkeiten, die auf Ihrem Hub Klassen, die wahrscheinlich der Fall für die meisten. Wenn Sie zu verwirren wollen um mit dem Einspritzen anderen Abhängigkeiten in SignalR, möchten Sie vielleicht zu gehen mit Steven ' s Antwort.

Probleme mit pro web-Anfrage Abhängigkeiten in einer Hub

Es ist eine interessante Sache über SignalR... wenn sich ein client trennt die Verbindung zu einem hub (zum Beispiel durch schließen Ihres browser-Fensters), wird eine neue Instanz der Hub Klasse in der Reihenfolge zu berufen OnDisconnected(). Wenn dies geschieht, HttpContext.Current null ist. Also, wenn dies Hub irgendwelche Abhängigkeiten hat, die registriert sind, pro web-Anfrage, irgendwas wird wohl schief gehen.

In Ninject

Habe ich ausprobiert, SignalR dependency injection mit Ninject und die ninject-signalr-dependency resolver auf nuget. Mit dieser Konfiguration, Abhängigkeiten gebunden sind .InRequestScope() erstellt werden transient, wenn Sie injiziert in eine Hub während ein trennen-Ereignis. Da HttpContext.Current null ist, ich nehme an, Ninject nur entscheidet, Sie zu ignorieren, und erstellen transiente Instanzen, ohne Ihnen zu sagen. Vielleicht gab es eine Konfigurationseinstellung zu sagen, ninject, Sie zu warnen, aber es war nicht der Standard.

In SimpleInjector

SimpleInjector auf der anderen Seite wird eine exception werfen, wenn ein Hub hängt von einer Instanz registriert mit WebRequestLifestlyle:

Die registrierten Delegaten für Typ NameOfYourHub hat eine Ausnahme ausgelöst. Die
registrierte Delegaten für Typ NameOfYourPerRequestDependency hat eine Ausnahme ausgelöst. Die
YourProject.Namespace.NameOfYourPerRequestDependency eingetragen
'PerWebRequest', aber die Instanz angefordert wird, die außerhalb des Kontext
ein HttpContext - (HttpContext.Strom ist null). Stellen Sie sicher, dass Instanzen, die mit
dieser lebensstil nicht gelöst werden konnten, während der Initialisierung der Anwendung
phase und bei der Ausführung auf einem hintergrund-thread. Für die Lösung Instanzen
auf hintergrund-threads, versuchen Sie die Registrierung dieser Instanz als " Pro Lebensdauer
Anwendungsbereich": https://simpleinjector.readthedocs.io/en/latest/lifetimes.html#scoped.

...Hinweis: diese Ausnahme wird nur sprudeln, wenn HttpContext.Current == null ist, soweit ich das beurteilen kann, passiert das nur, wenn SignalR Anfragen ein Hub Instanz, um zum aufrufen OnDisconnected().

Lösungen für pro web-Anfrage Abhängigkeiten in einer Hub

Beachten Sie, dass keines dieser sind wirklich ideal, es wird alles hängt von den Anforderungen Ihrer Anwendung.

In Ninject

Wenn Sie brauchen, non-transient-Abhängigkeiten, nicht nur überschreiben OnDisconnected() oder etwas zu tun, benutzerdefinierte es mit der Klasse Abhängigkeiten. Wenn Sie tun, jede Abhängigkeit im Diagramm wird eine separate (transient) Instanz.

In SimpleInjector

Benötigen Sie eine hybrid-lifestyle zwischen WebRequestLifestlye und entweder Lifestyle.Transient, Lifestyle.Singleton oder LifetimeScopeLifestyle. Wenn HttpContext.Current ist nicht null, Abhängigkeiten, die nur so lange Leben, wie die web-Anfrage, wie Sie normalerweise erwarten würden. Allerdings, wenn HttpContext.Current null ist, Abhängigkeiten werden entweder injiziert werden transient, als singletons oder innerhalb einer Lebensdauer Anwendungsbereich.

var lifestyle = Lifestyle.CreateHybrid(
    lifestyleSelector: () => HttpContext.Current != null,
    trueLifestyle: new WebRequestLifestyle(),
    falseLifestyle: Lifestyle.Transient //this is what ninject does
    //falseLifestyle: Lifestyle.Singleton
    //falseLifestyle: new LifetimeScopeLifestyle()
);

Mehr über LifetimeScopeLifestyle

In meinem Fall, ich habe eine EntityFramework DbContext Abhängigkeit. Diese kann tückisch sein, weil Sie zeigen Probleme bei der Anmeldung vorübergehend oder als singletons. Wenn Sie registriert sind transient, können Sie am Ende mit Ausnahmen beim Versuch, die Arbeit mit den Einheiten angebracht, um 2 oder mehr DbContext Instanzen. Wenn registriert als ein singleton, dass Sie am Ende mit mehr Allgemeinen Ausnahmen (nicht immer registrieren Sie einen DbContext als singleton). In meinem Fall brauchte ich die DbContext Leben in einem bestimmten Leben, in dem die selbe Instanz wiederverwendet werden kann über viele geschachtelte Operationen, was bedeutet, ich brauchte die LifetimeScopeLifestyle.

Nun, wenn du mit dem hybrid-code oben mit dem falseLifestyle: new LifetimeScopeLifestyle() line, bekommen Sie eine weitere Ausnahme, wenn Ihre benutzerdefinierte IHubActivator.Create - Methode wird ausgeführt:

Die registrierten Delegaten für Typ NameOfYourHub hat eine Ausnahme ausgelöst. Die
NameOfYourLifetimeScopeDependency ist registriert als 'LifetimeScope',
aber die Instanz angefordert wird, die außerhalb des Kontexts einer Lebensdauer Anwendungsbereich.
Stellen Sie sicher, dass Sie call-container.BeginLifetimeScope() zuerst.

Den Weg, Sie haben eine Lebensdauer scoped Abhängigkeit geht so:

using (simpleInjectorContainer.BeginLifetimeScope())
{
    //resolve solve dependencies here
}

Alle Abhängigkeiten eingetragen sind, mit lifetime Umfang gelöst werden müssen innerhalb dieses using block. Außerdem, wenn eine dieser Abhängigkeiten implementieren IDisposable Sie entsorgt werden, die am Ende der using block. Nicht versucht sein, so etwas zu tun:

public IHub Create(HubDescriptor descriptor)
{
    if (HttpContext.Current == null)
        _container.BeginLifetimeScope();
    return _container.GetInstance(descriptor.HubType) as IHub;
}

Fragte ich Steven (wer kommt auch zu dem SimpleInjector Autor in Fall, dass Sie nicht wissen) darüber, und er sagte:

Gut.. Wenn Sie nicht entsorgen Sie die LifetimeScope, werden Sie in großen
Schwierigkeiten, so stellen Sie sicher, Sie werden entsorgt. Wenn Sie nicht entsorgen Sie die
Bereiche, Sie wird hängen, um für immer in ASP.NET. Dies ist, weil
scopes können verschachtelt werden, und die Referenz Ihrer übergeordneten Bereich. So ein thread
am Leben hält, die am inneren Umfang (mit cache) und dieser Rahmen hält
lebendig übergeordneten Rahmen (mit cache) und so weiter. ASP.NET pools
threads und nicht zurücksetzen aller Werte, wenn es packt einen thread aus dem
pool, so bedeutet dies, dass alle Bereiche am Leben zu bleiben, und wenn Sie das nächste mal
schnappen Sie sich ein thread aus dem pool und beginnen ein neues Leben Umfang, Sie wird
erstellen Sie einfach einen neuen verschachtelten Rahmen-und dies wird immer stapeln sich.
Früher oder später, erhalten Sie eine OutOfMemoryException.

Können Sie nicht verwenden IHubActivator um den Umfang der Abhängigkeiten, weil Sie nicht so lange Leben wie die Hub Instanz, die es schafft. Also, auch wenn Sie verpackt die BeginLifetimeScope() Methode in einer using block, Ihre Abhängigkeiten entsorgt werden unmittelbar nach der Hub Instanz erstellt. Was Sie wirklich brauchen, hier ist eine andere Ebene der Dereferenzierung.

Was ich am Ende mit, mit viel Dank an Steven helfen, ist ein Befehl decorator (und eine Abfrage decorator). Ein Hub kann nicht davon abhängen, pro web-request-Instanzen selbst, sondern muss abhängig von einem anderen Schnittstelle, deren Umsetzung hängt von der per-request-Instanzen. Die Umsetzung eingespritzt wird, in die Hub Konstruktor ist eingerichtet (über simpleinjector) mit einem wrapper, der beginnt und über die Lebensdauer Anwendungsbereich.

public class CommandLifetimeScopeDecorator<TCommand> : ICommandHandler<TCommand>
{
    private readonly Func<ICommandHandler<TCommand>> _handlerFactory;
    private readonly Container _container;

    public CommandLifetimeScopeDecorator(
        Func<ICommandHandler<TCommand>> handlerFactory, Container container)
    {
        _handlerFactory = handlerFactory;
        _container = container;
    }

    [DebuggerStepThrough]
    public void Handle(TCommand command)
    {
        using (_container.BeginLifetimeScope())
        {
            var handler = _handlerFactory(); //resolve scoped dependencies
            handler.Handle(command);
        }
    }
}

... es ist die dekorierte ICommandHandler<T> Instanzen abhängen, die pro-web-request-Instanzen. Für mehr Informationen über das Muster, das verwendet wird, Lesen Sie diese und diese.

Beispiel Registrierung

container.RegisterManyForOpenGeneric(typeof(ICommandHandler<>), assemblies);

container.RegisterSingleDecorator(
    typeof(ICommandHandler<>),
    typeof(CommandLifetimeScopeDecorator<>)
);

Von SignalR 2.0 (und die beta) es ist eine neue Art der Einstellung der dependency resolver. SignalR verschoben OWIN startup um die Konfiguration. Mit Einfach Injektor-Sie würde es so machen:

public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        var config = new HubConfiguration()
        {
            Resolver = new SignalRSimpleInjectorDependencyResolver(Container)
        };
        app.MapSignalR(config);
    }
}

public class SignalRSimpleInjectorDependencyResolver : DefaultDependencyResolver
{
    private readonly Container _container;
    public SignalRSimpleInjectorDependencyResolver(Container container)
    {
        _container = container;
    }
    public override object GetService(Type serviceType)
    {
        return ((IServiceProvider)_container).GetService(serviceType)
               ?? base.GetService(serviceType);
    }

    public override IEnumerable<object> GetServices(Type serviceType)
    {
        return _container.GetAllInstances(serviceType)
            .Concat(base.GetServices(serviceType));
    }
}

Müsstest du explizit Spritzen Sie Ihre hubs so:

container.Register<MessageHub>(() => new MessageHub(new EFUnitOfWork()));

Diese config läuft live auf einem high-traffic-website ohne Probleme.