Jeden DbContext na żądanie www ... dlaczego?

Istnieją dwa sprzeczne zalecenia Microsoftu i wiele osób korzysta z DbContext w zupełnie odmienny sposób.

1. jedną z rekomendacji jest "pozbądź się DbContext jak najszybciej" ponieważ posiadanie DbContext Alive zajmuje cenne zasoby, takie jak db połączenia itp....
2. drugi stwierdza, że Jeden DbContext na żądanie jest wysoce reccomended

Te są ze sobą sprzeczne, ponieważ jeśli Twoja prośba robi wiele z niezwiązanych z DB rzeczy, a następnie DbContext jest przechowywane bez powodu. W ten sposób marnuje się DbContext, podczas gdy twoje żądanie czeka tylko na losowe rzeczy do zrobienia...

Tak wiele osób, które przestrzegają Zasady 1 ma swoje DbContext wewnątrz "wzorca repozytorium" i tworzy nową instancję na zapytanie bazy danych Tak x * DbContext na żądanie

Po prostu dostają swoje dane i pozbywają się kontekstu jak najszybciej. Jest to rozpatrywane przez Wielu ludzi jest akceptowalną praktyką. Chociaż ma to zalety zajmowania zasobów db przez minimalny czas, wyraźnie poświęca wszystkie UnitOfWork i buforowanie candy EF ma do zaoferowania.

Utrzymanie przy życiu pojedynczej wielozadaniowej instancji DbContext maksymalizuje korzyści z buforowania ale ponieważ DbContext jest nie bezpieczny dla wątku i każde żądanie sieci Web działa na własnym wątku, DbContext na żądanie jest najdłuższy można zatrzymaj to.

Więc rekomendacja zespołu EF o używaniu kontekstu 1 Db na żądanie jest wyraźnie oparta na fakcie, że w aplikacji internetowej UnitOfWork najprawdopodobniej będzie w jednym żądaniu i że żądanie ma jeden wątek. Tak więc jeden DbContext na żądanie jest idealną zaletą UnitOfWork i buforowania.

Ale w wielu przypadkach nie jest to prawdą. Uznaję Logging za oddzielną jednostkę pracy, dzięki czemu mamy nowy DbContext do logowania po żądaniu asynchronicznego wątki {[2] } jest całkowicie dopuszczalne

W końcu okazuje się, że żywotność DbContext jest ograniczona do tych dwóch parametrów. UnitOfWork i Thread

Ani jedna odpowiedź tutaj rzeczywiście odpowiada na pytanie. OP nie zapytał o projekt DbContext singleton / per-application, zapytał o projekt per - (web)request i jakie potencjalne korzyści mogą istnieć.

I ' ll reference http://mehdi.me/ambient-dbcontext-in-ef6 / jako że Mehdi jest fantastycznym zasobem:

Możliwy wzrost wydajności.

Każda instancja DbContext utrzymuje bufor pierwszego poziomu wszystkich elementów ładowanych z bazy danych. Za każdym razem, gdy odpytywasz obiekt za pomocą klucza podstawowego, DbContext najpierw spróbuje pobrać go z bufora pierwszego poziomu, a następnie domyślnie odpytywa go z bazy danych. W zależności od wzorca zapytań dotyczących danych, ponowne użycie tego samego DbContext w wielu sekwencyjnych transakcjach biznesowych może skutkować mniejszą liczbą zapytań do bazy danych dzięki buforowi pierwszego poziomu DbContext.

Umożliwia leniwe Ładowanie.

Jeśli Twoje usługi zwracają trwałe podmioty (w przeciwieństwie do zwracanie modeli widoku lub innych rodzajów Dto) i chcesz skorzystać z leniwego ładowania tych podmiotów, czas życia instancji DbContext, z której te podmioty zostały pobrane, musi wykraczać poza zakres transakcji biznesowej. Jeśli metoda service usunie instancję DbContext, której użyła przed zwróceniem, każda próba Lazy-load właściwości zwracanych elementów zakończy się niepowodzeniem (to, czy używanie Lazy-Load jest dobrym pomysłem, jest zupełnie inną debatą, którą nie dostanie się tutaj). W naszym przykładzie aplikacji webowej, leniwe ładowanie będzie zwykle używane w metodach akcji kontrolera na obiektach zwracanych przez oddzielną warstwę usług. W takim przypadku instancja DbContext, która została użyta przez metodę service do załadowania tych encji, musi pozostać żywa przez czas trwania żądania sieci web (lub przynajmniej do czasu zakończenia metody akcji).

Należy pamiętać, że są również minusy. Ten link zawiera wiele innych zasobów do przeczytania temat.

Po prostu zamieszczam to na wypadek, gdyby ktoś inny natknął się na to pytanie i nie został pochłonięty odpowiedziami, które tak naprawdę nie odnoszą się do pytania.

Jestem całkiem pewien, że to dlatego, że DbContext nie jest w ogóle Bezpieczny wątek. Więc dzielenie się tym nigdy nie jest dobrym pomysłem.

Jedna rzecz, która nie jest tak naprawdę poruszona w pytaniu lub dyskusji, to fakt, że DbContext nie może anulować zmian. Możesz przesyłać zmiany, ale nie możesz wyczyścić drzewa zmian, więc jeśli używasz kontekstu na żądanie, masz pecha, jeśli musisz wyrzucić zmiany z dowolnego powodu.

Osobiście tworzę instancje DbContext w razie potrzeby-zwykle dołączane do komponentów biznesowych, które mają możliwość odtworzenia kontekstu w razie potrzeby. W ten sposób mam kontrolę nad proces, a nie zmuszanie mnie do jednego wystąpienia. Nie muszę też tworzyć DbContext przy każdym uruchomieniu kontrolera, niezależnie od tego, czy rzeczywiście zostanie użyty. Następnie, jeśli nadal chcę mieć instancje na żądanie, mogę je utworzyć w CTOR (poprzez DI lub ręcznie) lub utworzyć je w razie potrzeby w każdej metodzie kontrolera. Osobiście zazwyczaj stosuję to drugie podejście, aby uniknąć tworzenia instancji DbContext, gdy nie są one rzeczywiście potrzebne.

To zależy z jakiego kąta Zobacz też Dla mnie instancja per request nigdy nie miała sensu. Czy DbContext naprawdę należy do żądania Http? Jeśli chodzi o zachowanie, to nie to miejsce. Komponenty biznesowe powinny tworzyć kontekst, a nie żądanie Http. Następnie możesz tworzyć lub wyrzucać komponenty Biznesowe w razie potrzeby i nigdy nie martwić się o żywotność kontekstu.

Zgadzam się z wcześniejszymi opiniami. Warto powiedzieć, że jeśli zamierzasz udostępniać DbContext w aplikacji single thread, będziesz potrzebował więcej pamięci. Na przykład moja aplikacja internetowa na platformie Azure (jedna dodatkowa mała instancja) potrzebuje jeszcze 150 MB pamięci i mam około 30 użytkowników na godzinę.

Oto przykładowy obrazek: aplikacja została wdrożona w 12PM

Podoba mi się w tym, że wyrównuje jednostkę pracy (jak widzi to użytkownik-tj. stronę submit) z jednostką pracy w sensie ORM.

W związku z tym możesz dokonać transakcji całego przesłania strony, czego nie możesz zrobić, jeśli ujawniasz metody CRUD z każdym tworzeniem nowego kontekstu.

Innym zaniżonym powodem nieużywania singleton DbContext, nawet w pojedynczej aplikacji z wątkiem pojedynczego użytkownika, jest wzór mapy tożsamości, którego używa. Oznacza to, że za każdym razem, gdy pobierasz dane za pomocą zapytania lub id, będzie ono przechowywać pobrane instancje encji w pamięci podręcznej. Następnym razem, gdy odzyskasz ten sam encja, otrzymasz buforowaną instancję encji, jeśli jest dostępna, z dowolnymi modyfikacjami wykonanymi w tej samej sesji. Jest to konieczne, aby oszczędzać metoda nie kończy się z wieloma różnymi instancjami encji tego samego rekordu bazy danych; w przeciwnym razie kontekst musiałby w jakiś sposób scalić dane ze wszystkich tych instancji encji.

Powodem, dla którego jest to problem, jest to, że singleton DbContext może stać się bombą zegarową, która może ostatecznie buforować całą bazę danych + narzut obiektów.NET w pamięci.

Istnieją sposoby obejścia tego zachowania, używając tylko zapytań Linq z metodą rozszerzenia .NoTracking(). Również w dzisiejszych czasach komputery mają dużo pamięci RAM. Ale zazwyczaj nie jest to pożądane zachowanie.

Inną kwestią, na którą należy zwrócić uwagę w przypadku struktury encji, jest użycie kombinacji tworzenia nowych encji, leniwego ładowania, a następnie używanie tych nowych encji (z tego samego kontekstu). Jeśli nie używasz IDbSet.Create (vs just new), leniwe Ładowanie tego elementu nie działa, gdy jego Pobrano z kontekstu, w którym został utworzony. Przykład:

 public class Foo {
     public string Id {get; set; }
     public string BarId {get; set; }
     // lazy loaded relationship to bar
     public virtual Bar Bar { get; set;}
 }
 var foo = new Foo {
     Id = "foo id"
     BarId = "some existing bar id"
 };
 dbContext.Set<Foo>().Add(foo);
 dbContext.SaveChanges();

 // some other code, using the same context
 var foo = dbContext.Set<Foo>().Find("foo id");
 var barProp = foo.Bar.SomeBarProp; // fails with null reference even though we have BarId set.