DbContext - wstrzykiwać czy nie wstrzykiwać?

Wstrzykiwać, czy nie wstrzykiwać - oto jest pytanie. Jakie są zalety i wady wstrzykiwania contextu? Pomińmy przy tym kwestie testów.
A jak już wstrzykiwać to z jakim scope?

Z zalet: no... że nie musisz go tworzyć :P

Scoped / Transient raczej

• możesz sobie tam wstrzyknąć jakąś konfigurację typu connection string na jednolitej zasadzie jak inne zależności
• nie musisz pamiętać o bloku using

Moim zdaniem wstrzykiwanie per httprequest (w .net Core AddScoped) . Wygodniej potem zrobić transakcje na różnych serwisach jeśli jest taka potrzeba.

W .net standardem jest wstrzykiwanie dla httprequest - dupiane rozwiazanie ale mozna z nim zyc. Lepiej aby scope byl jeden dla wywolania akcji serwisu (czyli jeszcze wywolasz 2 metody serwisowe w trakcie jednego zapytania httpwebrequest bedziesz mial 2 rozne dbContexty - dzieki temu ewentualne bledy/ustawienia z pierwszej akcji serwisowej nie beda mialy wplywu na 2 akcje serwisowa) - tylko tu juz trzeba kombinowac - wiec ma tez to swoje wady :).

Polecam przeczytać jakąś książkę o sql w szczególności działy poświęcone szeregowalności, niepodzielności i ogólnie izolacji operacji oraz problematyką współbieżności.

Potem zastanowić się, w jaki sposób ORM ułatwia lub automatyzuje te operacje.

W szczególności, jaką rolę w tym pełni Unit Of Work.

Odpowiedź stylu: "Wstrzykuj, nie wstrzykuj, bo tak się robi." Albo sławne już "Nie masz repozytorium to nie masz DDD" Nic ci nie da i w ten sposób odpowiadają nic niewarci dyletanci.