Hej,
z tego co widzę FNH nie wspiera async/await. W takim razie też pytanie czy go używacie czy nie?
Mam API do apki mobilnej, mam tam operacje IO do bazy danych i zastanawiam się na jakiej podstawie powinienem podjąć decyzje o używaniu async/await-ów przy tych operacjach. Możecie mi pomóc z tym?
Jeśli struktura Twojej bazy danych nie będzie się zmieniać (albo będzie się to działo rzadko) o Enitity Framework wspiera async/await. Jego użyłbym.
A jaki jest zysk z async/await na bazie?
@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?
@ekhart : moja DB nie będzie w runtime zmieniana. EF daje opcję używania async/await ale co z tego skoro używam FNH i to jest pytanie dotyczące tego rozwiązania.
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?
Ale async w api chyba nic nie ma do UI aplikacji Android.
Jak EF czy NH to odczyta to nie ma znaczenia.
Na Andoidzie zrób AsyncTask, który poczeka na dane z API i jak je dostanie to wyświetli. API i tak zwróci Ci fizycznie dane dopiero jak je wyciągnie z bazy. Albo użyj AsyncHttpClient do komunikacji.
Tu masz przykład z jakiejś mojej aplikacji z AsyncHttpClient, która wywołuje endpoint API i jak dostanie dane to zwraca w metodzie SetRollsInWysylka, która formatuje list e i wyświetla na ekranie
private void GetRollsInWysylka(int wysId)
{
// pobranie listy kręgów w dostawie
AsyncHttpClient client = new AsyncHttpClient();
RequestParams params = new RequestParams();
//params.add("DostawaId", String.valueOf(dostawa.Id));
String url = getConfig().getServerAddress() + ServiceUrl.WYSYLKA_GET_ROLLS+wysId;
client.get(this, url, new AsyncHttpResponseHandler() {
@Override
public void onSuccess(int statusCode, cz.msebera.android.httpclient.Header[] headers, byte[] responseBody) {
Log.d(TAG, "LoadDostawcy success..");
Gson gson = new Gson();
Type type = new TypeToken<ArrayList<RollFullViewModel>>(){}.getType();
ArrayList<RollFullViewModel> d = gson.fromJson(new String(responseBody), type);
SetRollsInWysylka(d);
}
@Override
public void onFailure(int statusCode, cz.msebera.android.httpclient.Header[] headers, byte[] responseBody, Throwable error) {
Log.d(TAG, "Błąd pobrania kręgów");
Toast.makeText(WysylkaViewActivity.this, "Wystąpił błąd pobrania kręgów", Toast.LENGTH_LONG).show();
}
});
}
to w Javie jakby co.
ne0 napisał(a):
@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. ;)
Ale zdaje się zakładasz tu że każdy request puka do bazy, a przecież część requestów może żądać dostępu do innych zasobów zewnętrznych. Wtedy dobrze jak by wątki czekające na odpowiedź z bazy też zostały zwolnione. Tak mi się wydaje.
dam1an napisał(a):
Ale zdaje się zakładasz tu że każdy request puka do bazy, a przecież część requestów może żądać dostępu do innych zasobów zewnętrznych. Wtedy dobrze jak by wątki czekające na odpowiedź z bazy też zostały zwolnione. Tak mi się wydaje.
Oczywiście, że dobrze, aby tak było. Ale nie każdy request musi pukać do bazy, żeby ją zapchać, czasem wystarczy, że zrobi to 10%. Kwestia co konkretnie serwis robi.