Is it useful to tag the async method when it only expects a return statement?

Question

Only the last line of the method below uses "wait", just before the method returns, so that does not mean that this method is mostly synchronous and should simply be called "Get ()" without the async modifier and the Async suffix?

public virtual async Task<TEntity> GetAsync(Guid id) { // some more code here return await _dbSet.FindAsync(id); } 

Answer 1

doesn't this mean that the method is mostly synchronous

Not. It is asynchronous. You are probably thinking of sequential (moving from one subject to another), rather than synchronous (blocking the current thread). await pauses the method (sequentially) but does not block the thread (asynchronously). For more information, see the async introduction .

without async modifier

While you can move away from the async / await keywords, I would recommend that you do not. This is because // some more code here may throw an exception. I will talk about this and other considerations in my blog post eliding async and await .

and the suffix Async?

No, this suffix is ​​suitable for any method that returns the expected one (for example, Task ). That way, even if you go back to async and await , it still returns the job you should expect, so it should have the suffix async .

You can think of it this way: the async suffix is ​​part of the API. The async is an implementation detail. They often go together, but not always.

Answer 2

This is a matter of opinion. Typically, a naming convention means anything that returns Task or Task<T> has an Async suffix.

Your example is higher, although it would be better to write so that you do not have unnecessary overhead for an asynchronous shell. This is because you do not need to wait for the result in this method. Then the consumer of the method expected the result if he used it directly.

 public virtual Task<TEntity> GetAsync(Guid id, params Expression<Func<TEntity, object>>[] includeProperties)) { // some more code here return _dbSet.FindAsync(id); } 

Answer 3

await not blocked. It expects an asynchronous operation to complete. This means that the original thread is freed on hold. In a desktop application, this means that the user interface thread is freed while waiting, for example, to complete HTTP or call the database.

When this operation completes, execution returns to the original thread (for desktop applications).

Be that as it may, you can simplify your code by removing the async and await keywords and immediately returning the task. The code does nothing with the results of the operation, so it does not need to wait for completion. This will be done by the caller of the method:

 public virtual Task<TEntity> GetAsync(Guid id) { // some more code here return _dbSet.FindAsync(id); } 

The real asynchronous operation in this FindAsync code. The async is just syntactic sugar that allows you to use the await keyword. If you don't need await , you don't need the async either

Answer 4

There are many cases where the suffix of any asynchronous method with Async is simply redundant. If your method returns Task or Task<T> , and its purpose is to obtain data from a database or other network resource, then, of course, it runs asynchronously. The compiler will also almost always give you an error if you forget to wait for something. With this in mind, there are several good reasons for suffixing asynchronous methods using Async :

• The method runs asynchronously, but does not return Task
• There is an alternative other method with the same name that runs synchronously
• Forgetting the wait when calling the code is unlikely to be caught by the compiler

The suffix of the method name with Async means that the method runs asynchronously, which this method does. Whether he uses it with async/await or directly returns another task - an implementation detail. Imagine you were looking at code that calls a method that forgets to use. Which of these makes the mistake more obvious?

 var item1 = _example.Get(itemId1); var item2 = _example.GetAsync(itemId2); 

Based on something else, there is no reason to believe that something is wrong with the first line. The second line, at least, will cause some eyebrows.