L'utilisation du suffixe "Async" dans le nom d'une méthode dépend-elle de l'utilisation du modificateur "async" ?

Question

Quelle est la convention pour suffixer les noms de méthodes avec "Async" ?

Faut-il ajouter le suffixe "Async" ? sólo à une méthode qui est déclarée avec l'option async modificateur ?

public async Task<bool> ConnectAsync()

Ou est-il suffisant que la méthode renvoie simplement Task<T> o Task ?

public Task<bool> ConnectAsync()

Answer 1

Je pense que la vérité est ambiguë même dans la documentation de Microsoft :

Dans Visual Studio 2012 et le .NET Framework 4.5, toute méthode qui est attribuée à la méthode async mot-clé ( Async en Visual Basic) est est considérée comme une méthode asynchrone, et le C# et le Visual Basic effectuent les transformations nécessaires pour mettre en œuvre la méthode de manière asynchrone en utilisant TAP. Une méthode asynchrone doit retourner soit un Task ou un Task<TResult> objet.

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

Ce n'est déjà pas bien. Toute méthode avec async est asynchrone et il dit ensuite qu'il devrait retourner soit un Task o Task<T> - ce qui ne convient pas aux méthodes situées au sommet d'une pile d'appels, Button_Click par exemple, ou encore async void .

Bien sûr, il faut se demander quel est l'intérêt de la convention.

On pourrait dire que le Async La convention du suffixe est destinée à communiquer à l'utilisateur de l'API que la méthode est attendable. Pour qu'une méthode soit attendable, elle doit renvoyer Task pour un vide, ou Task<T> pour une méthode de retour de valeur, ce qui signifie que seule cette dernière peut être suffixée par le suffixe Async .

Ou vous pourriez dire que le Async La convention du suffixe est de communiquer que la méthode peut retourner immédiatement, abandonnant le thread actuel pour effectuer d'autres travaux et causant potentiellement des courses.

Cette citation du document Microsoft dit :

Par convention, vous ajoutez "Async" au nom des méthodes qui ont un modificateur de type Async ou un modificateur async.

Contenu désormais disponible uniquement via la Wayback Machine

Ce qui ne mentionne même pas que vos propres méthodes asynchrones retournant Task besoin de la Async suffixe, ce que nous sommes tous d'accord pour dire qu'ils font.

---

La réponse à cette question pourrait donc être : les deux. Dans les deux cas, vous devez ajouter Async aux méthodes avec async et que le retour Task o Task<T> .

---

Je vais demander à Stephen Toub de clarifier la situation.

Mise à jour

C'est ce que j'ai fait. Et voici ce que notre brave homme a écrit :

Si une méthode publique renvoie des tâches et est asynchrone par nature (comme le fait l asynchrone (par opposition à une méthode dont on sait qu'elle est toujours synchrone jusqu'à la fin mais qui renvoie quand même une tâche pour une raison ou une autre), elle doit porter le suffixe "Async". un suffixe "Async". C'est la ligne directrice. L'objectif principal ici avec l'attribution de noms est de faire en sorte qu'il soit évident pour un consommateur de la consommateur de la fonctionnalité que la méthode invoquée n'accomplira probablement pas que la méthode invoquée ne terminera probablement pas tout son travail de manière synchrone. où la fonctionnalité est exposée avec des méthodes synchrones et asynchrones. de sorte que vous avez besoin d'un nom différent pour les distinguer. Comment l'implémentation asynchrone de la méthode n'a pas d'importance pour le la dénomination : le fait d'utiliser async/await pour obtenir l'aide du compilateur, ou si les types et méthodes de System.Threading.Tasks sont utilisés directement (ex. directement (par exemple TaskCompletionSource) n'a pas vraiment d'importance, puisque cela n'affecte pas la signature de la méthode pour le consommateur de la méthode. de la méthode.

Bien sûr, il y a toujours des exceptions à une directive. La plus notable dans le cas du nommage serait les cas où où la raison d'être d'un type entier est de fournir une fonctionnalité asynchrone. d'async, auquel cas avoir de l'async sur chaque méthode serait une par exemple, les méthodes de la tâche elle-même qui produisent d'autres tâches.

En ce qui concerne les méthodes asynchrones à retour nul, il n'est pas souhaitable de disposer de dans la surface publique, puisque l'appelant n'a pas de bon moyen de savoir savoir quand le travail asynchrone est terminé. Si vous devez exposer Si vous devez exposer une méthode asynchrone à retour nul publiquement, vous probablement avoir un nom qui indique que le travail asynchrone est en train d'être lancé. asynchrone, et vous pourriez utiliser le suffixe "Async" ici si cela avait un sens. Étant donné la rareté de ce cas, je dirais qu'il s'agit d'une décision au décision à prendre au cas par cas.

J'espère que cela vous aidera, Steve

L'orientation succincte de la première phrase de Stephen est suffisamment claire. Elle exclut async void car il est inhabituel de vouloir créer une API publique avec une telle conception, puisque la manière correcte d'implémenter un void asynchrone est de retourner un simple Task et laissez le compilateur faire sa magie. Cependant, si vous voulez une public async void puis en ajoutant Async est conseillé. Autres produits en haut de la pile async void les méthodes telles que les gestionnaires d'événements ne sont généralement pas publiques et n'ont pas d'importance/de qualification.

Pour moi, ça veut dire que si je me pose des questions sur les suffixes Async sur un async void je devrais probablement le transformer en un async Task afin que les appelants puissent l'attendre, puis ajoutez Async .

Answer 2

Je construis beaucoup de services API et d'autres applications qui font appel à d'autres systèmes, où la plupart de mon code est exécuté de manière asynchrone.

La règle d'or que je suis est la suivante :

S'il y a une méthode non-asynchrone et une méthode asynchrone qui renvoient la même chose je donne le suffixe Async à la méthode async. Sinon, non.

Exemples :

Une seule méthode :

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

Même méthode avec deux signatures :

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

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

C'est logique puisque ce sont les mêmes données qui sont renvoyées, mais la seule chose qui diffère est la suivante la manière de renvoyer les données et non les données elles-mêmes.

Je pense également que cette convention de nommage existe en raison de la nécessité d'introduire des méthodes asynchrones tout en maintenant une compatibilité ascendante.

Je soutiens que le nouveau code ne devrait pas utiliser le suffixe Async. C'est tout aussi évident que le type de retour de String, ou Int comme mentionné précédemment dans ce fil.

Answer 3

Quelle est la convention pour suffixer les noms de méthodes avec "Async".

Le site Modèle asynchrone basé sur les tâches (TAP) dicte que les méthodes doivent toujours retourner un Task<T> (ou Task ) et être nommé avec un Async ce qui est distinct de l'utilisation du suffixe async . Les deux sites Task<bool> Connect() y asyncTask<bool> Connect() compilera et s'exécutera sans problème, mais vous ne respecterez pas la convention de dénomination TAP.

La méthode doit-elle contenir le async ou est-ce suffisant pour qu'il renvoie simplement Task ?

Si le corps de la méthode (quel que soit le type de retour ou le nom) inclut await vous doit utiliser async ; et le compilateur vous dira "L'opérateur 'await' ne peut être utilisé que dans une méthode asynchrone. ...". Renvoi de Task<T> o Task n'est pas "suffisante" pour éviter d'utiliser async . Voir async (Référence C#) pour les détails.

C'est-à-dire, lesquelles de ces signatures sont correctes :

Les deux sites asyncTask<bool> ConnectAsync() y Task<bool> ConnectAsync() respecter correctement les conventions TAP. Vous pourriez siempre utiliser le async mais vous obtiendrez un avertissement du compilateur "Cette méthode asynchrone ne dispose pas des opérateurs 'await' et s'exécutera de manière synchrone. ..." si le corps de la méthode n'utilise pas le mot clé await .

Answer 4

ou est-ce suffisant pour qu'il renvoie simplement Task ?

Cela. Le site async Le mot-clé n'est pas le vrai problème ici. Si vous implémentez l'asynchronie sans utiliser le mot-clé async mot-clé, la méthode est toujours "asynchrone", au sens général du terme.

Answer 5

Je dirais qu'elle devrait utiliser le suffixe Async si elle renvoie une tâche, que la méthode soit déclarée avec l'attribut async ou non.

La raison en est que le nom est déclaré dans l'interface. L'interface déclare le type de retour qui est un Task . Ensuite, il existe deux implémentations de cette interface, l'une d'entre elles utilisant l'interface de type async l'autre ne le fait pas.

public interface IFoo
{
    Task FooAsync();
}

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

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