Warum Microsoft von warnen PerRequestLifetimeManager mit

Question

https://msdn.microsoft.com/en-us/library/microsoft.practices.unity.perrequestlifetimemanager(v=pandp.30).aspx heißt es:

Obwohl die PerRequestLifetimeManager Lebensdauer Manager korrekt funktionieren und in der Arbeit mit Stateful oder faden unsicheren Abhängigkeiten im Rahmen einer HTTP-Anforderung können helfen, es Im Allgemeinen ist es keine gute Idee, es zu verwenden, wenn es vermieden werden kann, da es bei falscher Verwendung oft zu schlechten Praktiken oder schwer zu findenden Fehlern im Anwendungscode des Endbenutzers führen kann. Es wird empfohlen, dass die Abhängigkeiten, die Sie registrieren, zustandslos sind und wenn während der Lebensdauer einer HTTP-Anforderung ein gemeinsamer Status zwischen mehreren Objekten vorhanden sein muss, können Sie einen zustandslosen Dienst verwenden, der diesen Status mithilfe der Items-Auflistung von explizit speichert und abruft das aktuelle Objekt.

Auf was für Fehler oder schlechte Praktiken bezieht sich die Warnung? Wie würde man es falsch gebrauchen? - Leider ist die Warnung nicht sehr spezifisch und daher schwer auf die reale Welt anzuwenden. Außerdem ist mir nicht klar, was Stateful in diesem Zusammenhang bedeutet.

IMHO ein typisches Szenario zur Verwendung des PerRequestLifetimeManager wäre eine Art von Datenbankverbindung (z. B. DbContext) oder ähnlich.

Answer 1

Sein Zweck wäre, nur eine Instanz pro Anfrage instanziieren, die (zum Beispiel) redundante Operationen und Nachschlagevorgänge während einer einzigen Anfrage verhindern könnte.

Die Gefahr besteht, wenn jemand annimmt, dass das erstellte Objekt ein guter Ort ist, um den Status während der Anfrage zu speichern. Die Idee der Abhängigkeitsinjektion ist, dass eine Klasse eine Abhängigkeit (üblicherweise eine Schnittstelle) empfängt und überhaupt nichts darüber "weiß", außer dass sie diese Schnittstelle implementiert.

Aber jemand könnte argumentieren, dass, wenn das Objekt während der gesamten Lebensdauer der Anfrage bestehen bleibt, es ein guter Ort ist, um den Zustand während der Anfrage aufrechtzuerhalten. Sie erstellen also ein komplexes Szenario, in dem eine Klasse die Abhängigkeit empfängt, einige Informationen darin speichert (wie das Festlegen einer Eigenschaft), und dann eine andere Klasse dieselbe Abhängigkeit empfängt und erwartet, diese Eigenschaft zu lesen.

Jetzt wurde der Zweck der Abhängigkeitsinjektion (Entkopplung) überwunden, weil Klassen eingebaute Annahmen über die Lebensdauer dieser Abhängigkeit haben und sogar Annahmen darüber beinhalten können, was andere Klassen mit dem Zustand von tun oder tun werden dieses Objekt. Das schafft ein Wirrwarr, in dem die Interaktion zwischen den Klassen schwer zu erkennen ist - sogar versteckt - und so leicht zu knacken ist.

Nehmen wir an, jemand bestimmt, dass der Lebensstil dieser Abhängigkeit vorübergehend sein sollte, nicht per Web-Anfrage. Plötzlich hören alle Verhaltensweisen der Klassen, die davon abhängen, nicht mehr wie erwartet auf. Entwickler sehen sich diese Klassen an und sehen, dass sich nichts geändert hat. Was ist passiert? Die Interaktion zwischen diesen Klassen war in erster Linie schwer zu erkennen, so dass das Problem schwer zu finden sein wird. Und wenn es einen triftigen Grund gab, warum der Lebensstil dieser Abhängigkeit geändert wurde, wird das Problem noch schwerer zu beheben sein.

Wenn wir den Status während einer Anfrage speichern müssen, sollten wir ihn an "normalen" Orten wie HttpContext setzen. Es gibt immer noch Platz für einige verwirrende Praktiken und Fehler, aber zumindest wissen wir, dass die HttpContext (per Definition) an eine bestimmte Anfrage gebunden ist.