-
Mamy kontroler A, który zawiera instancje obiektów B i C. Kontroler A nie korzysta bezpośrednio z DbContext, natomiast B i C tak. Czy B i C powinny zawierać własne, prywatne instancje DbContext? Czy lepszym podejściem byłoby tworzenie instancji DbContext w A i przekazywać ją jako parametr konstruktora w chwili tworzenia B i C? Wtedy B i C działają na tym samy obiekcie. Nie ma wtedy potrzeby tworzenia dwóch instancji DbContext.
-
Co się dzieje gdy użytkownik odwiedza daną stronę? Za każdym razem tworzona jest nowa instancja kontrolera, która jest używana tylko i wyłącznie do obsługi żądania danego użytkownika? W takim przypadku B i C mogłyby operować na tym samym DbContext, tworzonym przez kontroler. Co gdy użytkownik wykona inną akcję tego samego kontrolera? Kontroler jest tworzony na nowo?
-
Czy mając dwie różne instancje DbContext w dwóch wątkach, mamy gwarancję, że nie dojdzie do nieprawidłowości w danej tabeli, jeżeli oba obiekty Db chcą odczytać i modyfikować tę samą krotkę, tej samej tabeli w tym samym czasie? Gdyby oba wątki korzystały z tej samej instancji to mogłoby to doprowadzić do takiego problemu?
-
DbContextjest implementacją Unit of Work, więc tworzenie dwóch jego obiektów i używanie ich w jednej transakcji biznesowej jest utrudnianiem sobie życia. Twórz jeden kontekst i używaj go na potrzeby całej transakcji. Nie rób prywatnych zależności lecz wstrzykuj je z zewnątrz, najlepiej jakimś kontenerem DI. -
Tak. Za każdym requestem tworzony jest nowy kontroler, każda akcja jest oddzielnym requestem.
-
Wątki nie mają znaczenia, to zależy od poziomów izolacji transakcji. Domyślnie przy dwóch contextach (a więc dwóch oddzielnych transakcjach) ostatni wygra i zapisze swoje zmiany. Jeśli kontekst będzie jeden, to zostaną po prostu wykonane wszystkie operacje, które na nim wywołasz. Pamiętaj, że wywołanie metody na contexcie to nie jest operacja na bazie, te zachodzą dopiero gdy zawołasz
SaveChanges.
Dokładnie tak jak napisał @somekind. Kontener DI nadaje się w takiej sytuacji doskonale. Staraj się nie tworzyć takich powiązań bo powstaje spaghetti code, które z czasem ciężko utrzymać.