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?
0
2
Z zalet: no... że nie musisz go tworzyć :P
Scoped / Transient raczej
2
- 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
2
Moim zdaniem wstrzykiwanie per httprequest (w .net Core AddScoped) . Wygodniej potem zrobić transakcje na różnych serwisach jeśli jest taka potrzeba.
1
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 :).
0
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.