Ich habe einen Code wie folgt in einem Tutorial von EF code first , MVC und StructureMap gesehen, um ein Context Per Request Muster zu erstellen:
FirstEntity , SecondEntity und ... alle benötigen IunitOfWork in ihrem Konstruktor.
Wie Sie sehen können, verwendet es nur HttpContextScoped() für die Context nicht andere und im EndRequest -Ereignis ruft es ReleaseAndDisposeAllHttpScopedObjects() auf.
1- ist das ein richtiger Ansatz?
2- soll ich HttpContextScoped () für alle anderen Service layer Interfaces oder nicht nur für IUnitOfWork verwenden? z. B.
oder
%Vor% 3- ReleaseAndDisposeAllHttpScopedObjects() entledigt alle Instanzen oder disponiert nur Context ?
Die Konvention für Webanwendungen besteht darin, dass Sie während der gesamten HTTP-Anfrage denselben ORM-Kontext / UnitOfWork beibehalten. Dies ist erforderlich, um während der Anforderung mit denselben Entitäten zu arbeiten, die Daten konsistent zu halten und die durchgeführten Datenbankaufrufe zu minimieren. Der HttpContextScoped -Lebenszyklus stellt sicher, dass die gleiche UoW-Instanz während einer Anfrage für alle Instanzen verwendet wird, die davon abhängig sind.
Also 1) ja, es ist richtig
Was den Rest der "Service-Layer-Schnittstellen" betrifft, hängt es davon ab, ob es während der gesamten Anfrage dieselbe Instanz sein muss. Fragen Sie sich selbst: "Wird der Zustand dieses Objekts während der gesamten Anfrage benötigt?" Für die meisten "Dienste" ist dies nicht der Fall. Beachten Sie auch, dass durch das Erstellen von "HttpContextScoped" alle Abhängigkeiten während dieses Bereichs beibehalten werden.
Das führt mich zu 2) In den meisten Fällen nein
ReleaseAndDisposeAllHttpScopedObjects entsorgt alle Objekte in dem mit HttpContextScoped registrierten Container. Standardmäßig werden Objekte in Transaction (neue Instanz pro Aufruf) in Struktur zugeordnet.
Also 3) Nur die IUnitOfWork Instanz wird entsorgt.
Tags und Links asp.net-mvc-3 entity-framework structuremap session-per-request