Czy użycie sufiksu „Async” w nazwie metody zależy od tego, czy używany jest modyfikator „async”?

Jaka jest konwencja dodawania sufiksów do nazw metod z „Async”?

Czy przyrostek „Async” powinien być dodawany tylko do metody zadeklarowanej za pomocą asyncmodyfikatora?

public async Task<bool> ConnectAsync()

Czy wystarczy, że metoda po prostu zwróci Task<T>lub Task?

public Task<bool> ConnectAsync()

Myślę, że prawda jest niejednoznaczna nawet z dokumentacji Microsoftu:

W programie Visual Studio 2012 i .NET Framework 4.5 każda metoda, której przypisano asyncsłowo kluczowe ( Asyncw języku Visual Basic), jest uważana za metodę asynchroniczną, a kompilatory C # i Visual Basic wykonują niezbędne transformacje, aby zaimplementować metodę asynchronicznie przy użyciu TAP. Metoda asynchroniczna powinna zwracać obiekt Tasklub Task<TResult>obiekt.

http://msdn.microsoft.com/en-us/library/hh873177(v=vs.110).aspx

To już nie w porządku. Każda metoda z asyncjest asynchroniczna, a następnie mówi, że powinna zwracać albo Tasklub Task<T>- co nie jest właściwe dla metod na górze stosu wywołań, na przykład Button_Click lub async void.

Oczywiście trzeba się zastanowić, jaki jest cel tej konwencji?

Można powiedzieć, że Asynckonwencja sufiksu polega na komunikowaniu użytkownikowi API, że metoda jest oczekiwana. Aby metoda była oczekiwana, musi zwrócić Taskdla void lub Task<T>dla metody zwracającej wartość, co oznacza, że ​​sufiksem może być tylko ta ostatnia Async.

Lub możesz powiedzieć, że Async konwencja sufiksu polega na komunikowaniu, że metoda może powrócić natychmiast, porzucając bieżący wątek w celu wykonania innej pracy i potencjalnie powodując wyścigi.

Ten cytat z dokumentu Microsoft mówi:

Zgodnie z konwencją dodajesz „Async” do nazw metod, które mają modyfikator Async lub async.

http://msdn.microsoft.com/en-us/library/hh191443.aspx#BKMK_NamingConvention

Co nawet nie wspomina, że ​​zwracanie własnych metod asynchronicznych Taskwymaga Asyncsufiksu, co, jak sądzę, wszyscy się zgadzamy.

Zatem odpowiedź na to pytanie może brzmieć: jedno i drugie. W obu przypadkach musisz dołączyć Asyncdo metod asyncsłowo kluczowe i zwrot Tasklub Task<T>.

Mam zamiar poprosić Stephena Tubusa o wyjaśnienie sytuacji.

Aktualizacja

Więc zrobiłem. A oto, co napisał nasz dobry człowiek:

Jeśli metoda publiczna zwraca Task i ma charakter asynchroniczny (w przeciwieństwie do metody, o której wiadomo, że zawsze jest wykonywana synchronicznie do zakończenia, ale z jakiegoś powodu nadal zwraca Task), powinna mieć przyrostek „Async”. To jest wskazówka. Podstawowym celem nazewnictwa jest pokazanie konsumentowi funkcjonalności, że wywoływana metoda prawdopodobnie nie zakończy synchronicznie całej swojej pracy; oczywiście pomaga to również w przypadku, gdy funkcjonalność jest ujawniana zarówno przy użyciu metod synchronicznych, jak i asynchronicznych, tak że do ich rozróżnienia potrzebna jest różnica nazw. Sposób, w jaki metoda osiąga swoją asynchroniczną implementację, jest nieistotny dla nazewnictwa: czy async / await jest używane do uzyskania pomocy kompilatora, czy też typy i metody z System.Threading.Tasks są używane bezpośrednio (np. sol. TaskCompletionSource) nie ma tak naprawdę znaczenia, ponieważ nie ma to wpływu na podpis metody, jeśli chodzi o konsumenta metody.

Oczywiście zawsze są wyjątki od wytycznych. Najbardziej zauważalnym w przypadku nazewnictwa byłyby przypadki, w których racją bytu całego typu jest zapewnienie funkcjonalności zorientowanej na asynchronię, w którym to przypadku posiadanie Async na każdej metodzie byłoby przesadą, np. Metody na samym Task, które generują inne zadania .

Jeśli chodzi o metody asynchroniczne zwracające void, nie jest pożądane, aby znajdowały się w obszarze publicznym, ponieważ obiekt wywołujący nie ma dobrego sposobu na sprawdzenie, kiedy praca asynchroniczna została zakończona. Jeśli jednak musisz publicznie ujawnić metodę asynchroniczną zwracającą void, prawdopodobnie chcesz mieć nazwę, która będzie wskazywać, że praca asynchroniczna jest inicjowana, i możesz użyć tutaj sufiksu „Async”, jeśli ma to sens. Biorąc pod uwagę, jak rzadki powinien być ten przypadek, twierdzę, że to tak naprawdę decyzja indywidualna.

Mam nadzieję, że to pomoże, Steve

Zwięzłe wskazówki zawarte w pierwszym zdaniu Stefana są wystarczająco jasne. Wyklucza, async voidponieważ tworzenie publicznego API o takim projekcie jest niezwykłe, ponieważ prawidłowym sposobem implementacji asynchronicznej pustki jest zwrócenie prostej Taskinstancji i pozwolenie kompilatorowi na jego magię. Jeśli jednak chcesz mieć public async voidrozszerzenie , zalecamy dołączenie Async. Inne async voidmetody top-of-stack , takie jak programy obsługi zdarzeń, zwykle nie są publiczne i nie mają znaczenia / kwalifikują się.

Dla mnie mówi mi, że jeśli zastanawiam się nad dodawaniem sufiksu Asyncdo a async void, prawdopodobnie powinienem zmienić go na znak , async Taskaby dzwoniący mogli na niego poczekać, a następnie dołączyć Async.

Tworzę wiele usług API i innych aplikacji, które wywołują inne systemy, w których większość mojego kodu działa asynchronicznie.

Oto moja praktyczna zasada:

Jeśli istnieje metoda nie-asynchroniczna i asynchroniczna, które zwracają to samo, sufikuję tę asynchroniczną z Async. W przeciwnym razie nie.

Przykłady:

Tylko jedna metoda:

public async Task<User> GetUser() { [...] }

Ta sama metoda z dwoma podpisami:

public User GetUser() { [...] }

public async Task<User> GetUserAsync() { [...] }

Ma to sens, ponieważ zwracane są te same dane, ale jedyną różnicą jest sposób ich zwracania , a nie same dane.

Myślę też, że te konwencje nazewnictwa istnieją ze względu na potrzebę wprowadzenia metod asynchronicznych i nadal zachowują kompatybilność wsteczną.

Twierdzę, że nowy kod nie powinien używać sufiksu Async. Jest to tak samo oczywiste, jak zwracany typ String lub Int, jak wspomniano wcześniej w tym wątku.

Jaka jest konwencja dodawania sufiksów do nazw metod z „Async”.

Te zadania opartego Asynchroniczna Wzór (TAP) mówi, że metody powinny zawsze zwraca Task<T>(a Task) i są nazwane z Async końcówką; jest to niezależne od użycia async. Oba Task<bool> Connect()i będą się kompilować i działać dobrze, ale nie będziesz przestrzegać konwencji nazewnictwa TAP.asyncTask<bool> Connect()

Czy metoda powinna zawierać asyncmodyfikator, czy wystarczy, że po prostu zwraca Task?

Jeśli treść metody (niezależnie od zwracanego typu lub nazwy) zawiera await, należy użyć async; a kompilator powie Ci „Operator 'await' może być używany tylko w ramach metody asynchronicznej. ...”. Zwrot Task<T>lub Tasknie jest wystarczający, aby uniknąć używania async. Aby uzyskać szczegółowe informacje, zobacz async (odwołanie w C #) .

Czyli które z tych podpisów są poprawne:

Obie i prawidłowo przestrzegaj konwencji TAP. Zawsze możesz użyć słowa kluczowego, ale otrzymasz ostrzeżenie kompilatora „Ta metoda asynchroniczna nie ma operatorów„ await ”i będzie działać synchronicznie. ...”, jeśli ciało nie używa .asyncTask<bool> ConnectAsync()Task<bool> ConnectAsync()asyncawait

czy wystarczy, że po prostu zwraca Task?

Że. Słowo asynckluczowe nie jest tutaj prawdziwym problemem. Jeśli zaimplementujesz asynchroniczność bez użycia asyncsłowa kluczowego, metoda jest nadal „Async” w sensie ogólnym.

Ponieważ Taski Task<T>to zarówno awaitable typy stanowią one część działanie asynchroniczne. A przynajmniej powinni reprezentować.

Należy dodać sufiks Asyncdo metody, która w niektórych przypadkach (niekoniecznie we wszystkich) nie zwraca wartości, a raczej zwraca opakowanie wokół trwającej operacji. Zwykle jest to opakowanie Task, ale w systemie Windows RT może to być IAsyncInfo. Podążaj za swoim przeczuciem i pamiętaj, że jeśli użytkownik twojego kodu zobaczy Asyncfunkcję, będzie wiedział, że wywołanie tej metody jest oddzielone od wyniku tej metody i że musi odpowiednio działać.

Zauważ, że istnieją metody, takie jak Task.Delayi, Task.WhenAllktóre zwracają, Taskale nie mają rozszerzeniaAsync sufiksu.

Zauważ również, że istnieją async voidmetody, które reprezentują metodę asynchroniczną odpal i zapomnij i powinieneś mieć świadomość, że metoda jest zbudowana w taki sposób.

Twierdziłbym, że powinien używać sufiksu Async, jeśli zwraca Task, niezależnie od tego, czy metoda jest zadeklarowana z asyncmodyfikatorem, czy nie.

Powodem jest to, że nazwa jest zadeklarowana w interfejsie. Interfejs deklaruje zwracany typ, którym jest Task. Następnie istnieją dwie implementacje tego interfejsu, jedna implementacja implementuje go za pomocą asyncmodyfikatora, a druga nie.

public interface IFoo
{
    Task FooAsync();
}

public class FooA : IFoo
{
    public Task FooAsync() { /* ... */ }
}

public class FooB : IFoo
{
    public async Task FooAsync() { /* ... */ }
}

W programowaniu asynchronicznym z async i await (C #) firma Microsoft oferuje następujące wskazówki:

Konwencja nazewnictwa

Zgodnie z konwencją dodajesz „Async” do nazw metod, które mają asynchroniczne modyfikator .

Możesz zignorować konwencję, w której zdarzenie, klasa bazowa lub kontrakt interfejsu sugeruje inną nazwę. Na przykład nie należy zmieniać nazw typowych programów obsługi zdarzeń, takich jak Button1_Click.

Uważam, że te wskazówki są niekompletne i niezadowalające. Czy to oznacza, że ​​w przypadku braku asyncmodyfikatora ta metoda powinna być nazwana Connectzamiast ConnectAsync?

public Task<bool> ConnectAsync()
{
    return ConnectAsyncInternal();
}

Nie sądzę. Jak wskazano w odpowiedzi zwięzłej przez @Servy i bardziej szczegółową odpowiedź przez @Luke Puplett , wierzę, że jest to właściwe i rzeczywiście oczekiwać, że metoda ta powinna być nazwane ConnectAsync(ponieważ zwraca awaitable). Na dalsze poparcie, @John Skeet w tej odpowiedzi na inne pytanie dołącza Asyncdo nazwy metody, niezależnie od obecności asyncmodyfikatora.

Wreszcie, w innym pytaniu , należy rozważyć ten komentarz przez @Damien_The_Unbeliever :

async/awaitto szczegóły implementacji twoich metod. Nie ma znaczenia, czy twoja metoda jest zadeklarowana, async Task Method()czy tylko Task Method(), jeśli chodzi o twoich wywołujących . (W rzeczywistości możesz swobodnie przełączać się między tymi dwoma w późniejszym czasie, bez uznawania tego za przełomową zmianę).

Z tego wnioskuję, że to asynchroniczny charakter metody decyduje o tym, jak należy ją nazwać. Użytkownik metody nie będzie nawet wiedział, czy asyncmodyfikator jest używany w jej implementacji (bez kodu źródłowego C # lub CIL).