Sollte ich OwinContext Umgebung zu halten anwendungsspezifische Daten pro Anfrage
Ich brauche einen Weg, um ein logging-Objekt pro Anfrage. Mit HttpContext ich würde gerne noch etwas hinzufügen, um die Elemente Dictionary. Ich will nicht zu bringen HttpContext in diesem, wenn ich helfen kann.
Der code unten ist, was ich Vorschlage, für eine Einheit LifeTimeManager speichern der Objekte in OwinContext Umgebung Eigenschaft, die ich zur Verfügung habe, um mit meine Owin-middleware.
public class OwinContextLifetimeManager : LifetimeManager
{
private string key = (new Guid()).ToString();
private IDictionary<string, object> environment;
public OwinContextLifetimeManager(IDictionary<string, object> environment)
{
this.environment = environment;
}
public override object GetValue()
{
if (environment != null && environment.ContainsKey(key))
return environment[key];
else
return null;
}
public override void RemoveValue()
{
if (environment != null)
environment.Remove(key);
}
public override void SetValue(object newValue)
{
if (environment != null)
environment[key] = newValue;
}
}
Dann kann ich es verwenden, wie dies von meinem middleware:
container.RegisterType<IRequestLog, RequestLog>(new OwinContextLifetimeManager(environment));
Fällt mir ein, dass ich wählen kann, was Schlüssel ich will, außer diejenigen, die bereits reserviert sind Owin.
Gibt es irgendeinen Grund, warum ich, sollten Sie nicht verwenden die OwinContext.Umwelt für diesen Zweck? Die MSDN-Dokumentation ist vage auf den best practices von diesem.
Darrel Miller ' s Antwort hier: Wie Lagere ich pro Anfrage Daten bei der Nutzung von OWIN Selbst Hosten ASP.NET Web-API führt mich zu glauben, dass die properties-Auflistung des request-Objekts ist der Weg zu gehen. Wie kann ich Zugriff auf dieses Objekt von middleware?
Ich weiß, das ist eine alte Frage, aber ich möchte nur zu beachten, wo generieren Sie Ihre Schlüssel
new Guid()
sollte Guid.NewGuid()
. new Guid()
erstellt eine leere guid (alle Nullen - Guid.Empty
) jedes mal.Gut zu wissen. Stellt sich heraus, da speichert er es in den Kontext der Anfrage, ich habe gerade verwendet eine Konstante anstelle von speichern eine ID haben.
InformationsquelleAutor codetoast | 2014-12-08
Du musst angemeldet sein, um einen Kommentar abzugeben.
OWIN Umwelt Wörterbuch verwendet werden kann zum speichern von per-request-Daten. Properties-Auflistung des request-Objekts kann verwendet werden, um das gleiche zu tun.
Der wesentliche Unterschied ist, OWIN Umwelt Wörterbuch ist eine OWIN-Konzept und ist anwendbar auf allen middleware läuft in einer OWIN-host. Properties-Auflistung des request-Objekts ist eine ASP.NET Web-API-Konzept und ist nur gültig, spezifische Rahmenbedingungen.
BTW, ASP.NET Web-API selbst läuft als middleware in der OWIN-pipeline. Also, um Ihre Frage zu beantworten, können Sie nicht auf das request-properties-Auflistung der Web-API aus der middleware, denn Sie gilt nur für die Web-API-middleware (oder bestimmten Rahmen).
Wenn Sie wollen, schreiben Sie Ihre cross-cutting concern Zeug als OWIN-middleware müssen Sie OWIN Umgebung-Wörterbuch. Wenn Web-API-Erweiterung Punkte wie ein filter oder ein message-handler ist okay, dann kann man die properties-Auflistung.
Offensichtlich, alles, was Sie schreiben, Nutzung von Web-API-Erweiterung-Punkte gilt nur für die Web-API in der Erwägung, dass OWIN-middleware ist anwendbar auf jede Art von app, die in der OWIN-pipeline und verfügt über Web-API.
Viel text, wenig Sinn. Weitere Argumente: Parallelität? HttpContext.Aktuelle.Artikel vs Owin Umwelt-Differenzen? Owin FILO und die Bedeutung der Registrierung middlewares.. hören Möchten mehr über konkrete Dinge, sondern als "Web-API verwendet" => Wir sollten auch..
InformationsquelleAutor Badri