@somekind: jaka jest?? nie wiem, WYDAJE mi się że zapis do DB ogólnie powinien być asynchroniczny. Tworzę apkę mobilną wraz z API, jeśli user wykona akcję która musi np. odpytać bazę no to sam odczyt DB powinien być asynchroniczny tak?
Ale co to daje użytkownikowi, czy to będzie asynchroniczne czy nie? Podejrzewam, że większość użytkowników nawet nie zna tego słowa. Użytkownik chce, aby aplikacja działało szybko, nie zamrażała interfejsu, a jeśli robi coś długo, to żeby informowała o tym.
Ale tak sobie myślę: skoro metody w kontrolerach API mam async/await to sam odczyt DB gdzieś głębiej już chyba takowy nie musi być nie?
Nie, nie musi. I właściwie niczego nie daje.
W asynchronicznym API chodzi o to, aby serwer mógł obsłużyć więcej żądań. Bez asynchroniczności wątek przetwarzający żądanie jest zablokowany dopóki nie skończy swojej pracy. Jeśli działamy asynchronicznie, to wątek przetwarzający żądanie może zostać zwrócony do puli dostępnej dla serwera na czas wykonywania operacji na zasobie zewnętrznym. To zwiększa wydajność serwera WWW, bo zamiast biernie czekać aż np. skończy się odczyt z dysku czy pobieranie danych z innego serwisu, może zająć się żądaniem od następnego użytkownika, a więc w tym samym czasie przetworzy ich więcej.
W przypadku operacji bazodanowych też w teorii można zyskać, bo to przecież też dostęp do zewnętrznego zasobu. Tylko, że jeśli baza danych jest jedna, i wszystkie żądania z niej korzystają, to zysku żadnego nie będzie - bo serwer webowy może przetworzyć na raz więcej żądań niż bazodanowy. W tym przypadku baza będzie wąskim gardłem, więc walka o asynchroniczne za wszelką cenę zapytania nie ma sensu. Dlatego też ten ficzer w EF to taki spojler do trabanta. ;)