Czy wykonywanie długich połączeń jest tak proste?

Question

Po prostu dla uproszczonego szkicu przekonwertowałem wiele metod dostępu do danych na asynchroniczne, używając następującego wzorca, a zbyt proste wydaje się być wystarczająco dobre dla późniejszych iteracji. Jak bezpieczne jest to, czego brakuje i jak mam to robić?

Usługa, która zapewnia doskonałe prowadzenie rozmów:

private class UserService 
{ 
    public IdentityUser GetById(int id) 
    { 
     ... 
    } 
} 

private UserService _userService = new UserService(); 

Oryginalny sposób synchroniczny:

public IdentityUser GetById(int id) 
{ 
    return _userService.GetById(id); 
} 

Mój fantastyczny nowy sposób asynchroniczny:

public async Task<IdentityUser> GetByIdAsync(int id) 
{ 
    await Task.Run(() => _userService.GetById(id)); 
} 

Answer 1

Nie należy uczynić " fałszywe asynchroniczne "metody takie jak ta:

public async Task<IdentityUser> GetByIdAsync(int id) 
{ 
    await Task.Run(() => _userService.GetById(id)); 
} 

Powód, dla którego nazywam to "fałszywym asynchronizowaniem", jest taki, że nie ma nic nierozerwalnie asynchronicznego względem operacji. W takim przypadku powinieneś mieć tylko metodę synchroniczną. Jeśli osoba dzwoniąca chce to zrobić asynchronicznie, używając Task.Run, może to zrobić.

Kiedy coś jest z natury asynchroniczne? Po wysłaniu żądania do usługi WWW lub bazy danych, na przykład, między wysłaniem żądania a odebraniem odpowiedzi jest okres oczekiwania - żądanie jest operacją wewnętrznie asynchroniczną. Aby uniknąć blokowania wywołującego wątku, użyj async-await.

Answer 2

Technicznie, że działa, ale działa poprzez utworzenie nowej nici do wykonywania synchronicznego operację, która sama jest zawijany i zablokowania z natury asynchronicznego pracy. Oznacza to, że nie uzyskujesz większych korzyści z przejścia na async w pierwszej kolejności.

Właściwa droga to przejście asynchroniczne do końca. Natomiast teraz prawdopodobnie masz coś takiego:

private class UserService 
{ 
    public IdentityUser GetById(int id) 
    { 
     return mContext.Users.Single(u => u.Id == id); 
    } 
} 

... należy teraz utworzyć wersji asynchronicznej:

private class UserService 
{ 
    public async Task<IdentityUser> GetByIdAsync(int id) 
    { 
     return await mContext.Users.SingleAsync(u => u.Id == id); 
    } 
} 

Zastosowanie:

public async Task<IdentityUser> GetByIdAsync(int id) 
{ 
    return await _userService.GetByIdAsync(id); 
} 

zakładając, oczywiście, że Twoja podstawowa struktura obsługuje asynchroniczne metody, takie jak SingleAsync() dla operacji z natury asynchronicznych, dzięki temu system może zwolnić bieżący wątek podczas oczekiwania na magistrale danych e operacja do ukończenia. Wątek można ponownie wykorzystać w innym miejscu, a po zakończeniu operacji można użyć dowolnej dostępnej nici w tym czasie.

Prawdopodobnie warto również przeczytać i przyjąć these Best Practices. Prawdopodobnie będziesz chciał użyć numeru .ConfigureAwait(false) w dowolnym miejscu, w którym nie masz dostępu do informacji kontekstowych, takich jak sesje i żądania.

Ta odpowiedź zakłada oczywiście, że GetById jest z natury asynchroniczny: pobierasz go z dysku twardego lub lokalizacji sieciowej lub coś podobnego. Jeśli oblicza się identyfikator użytkownika przy użyciu długotrwałej pracy procesora, to dobrym pomysłem jest przejście na Task.Run() i prawdopodobnie będziesz chciał dodatkowo określić, że jest to długotrwałe zadanie w argumentach dla Task.Run().

Answer 3

Funkcja Task.Run() powinna być używana tylko do pracy związanej z procesorem. Nie do końca pamiętam dlaczego. Spróbuj utworzyć metodę GetByIdAsync(), która ostatecznie wywoła zasób asynchroniczny.