C# – Aren’t the guidelines of async/await usage in C# contradicting the concepts of good architecture and abstraction layering

Architectureasyncc

This question concerns the C# language, but I expect it to cover other languages such as Java or TypeScript.

Microsoft recommends best practices on using asynchronous calls in .NET. Among these recommendations, let's pick two:

change the signature of the async methods so that they return Task or Task<> (in TypeScript, that'd be a Promise<>)
change the names of the async methods to end with xxxAsync()

Now, when replacing a low-level, synchronous component by an async one, this impacts the full stack of the application. Since async/await has a positive impact only if used "all the way up", it means the signature and method names of every layer in the application must be changed.

A good architecture often involves placing abstractions between each layers, such that replacing low-level components by others is unseen by the upper-level components. In C#, abstractions take the form of interfaces. If we introduce a new, low-level, async component, each interface in the call stack needs to be either modified or replaced by a new interface. The way a problem is solved (async or sync) in an implementing class is not hidden (abstracted) to the callers anymore. The callers have to know if it's sync or async.

Aren't async/await best practices contradicting with "good architecture" principles?

Does it mean that each interface (say IEnumerable, IDataAccessLayer) needs their async counterpart (IAsyncEnumerable, IAsyncDataAccessLayer) such that they can be replaced in the stack when switching to async dependencies?

If we push the problem a little further, wouldn't it be simpler to assume every method to be async (to return a Task<> or Promise<>), and for the methods to synchronize the async calls when they're not actually async? Is this something to be expected from the future programming languages?

Best Answer

What Color Is Your Function?

You may be interested in Bob Nystrom's What Color Is Your Function¹.

In this article, he describes a fictional language where:

Each function has a color: blue or red.
A red function may call either blue or red functions, no issue.
A blue function may only call blue functions.

While fictitious, this happens quite regularly in programming languages:

In C++, a "const" method may only call other "const" methods on this.
In Haskell, a non-IO function may only call non-IO functions.
In C#, a sync function may only call sync functions².

As you have realized, because of these rules, red functions tend to spread around the code base. You insert one, and little by little it colonizes the whole code base.

¹ Bob Nystrom, apart from blogging, is also part of the Dart team and has written this little Crafting Interpreters serie; highly recommended for any programming language/compiler afficionado.

² Not quite true, as you may call an async function and block until it returns, but...

Language Limitation

This is, essentially, a language/run-time limitation.

Language with M:N threading, for example, such as Erlang and Go, do not have async functions: each function is potentially async and its "fiber" will simply be suspended, swapped out, and swapped back in when it's ready again.

C# went with a 1:1 threading model, and therefore decided to surface synchronicity in the language to avoid accidentally blocking threads.

In the presence of language limitations, coding guidelines have to adapt.

Related Solutions

C# – Correct usage of async/await and Task.Run()

At first glance, I would say the async/await code looks OK. However, there are a few things to consider.

Don't change global or class state in a task. Have the task be a true function (i.e. does not use or alter global or class state). Example in LoadFilesAsync()
When the code to run is small enough, the task overhead is worse than just running the code in place (example in LoadFilesAsync()).
I assume this is temporary, but MessageBox.ShowMessage() isn't a good idea deep in your tasks (example in RunTestsAsync() when the handling class also does the same thing)

In your LoadFilesAsync() method I would restructure it like this:

private async Task<IEnumerable<MyFile>> LoadFilesAsync()
{
    // Multiple tasks clearing state can step on each other's toes.
    // It's better to return the set of files and then have the receiver
    // code merge them or do work with it directly.
    List<MyFile> files = new List<MyFile>();

    foreach (var file in Files)
    {
        file.FileLoadStatus = Enums.FileLoadStatus.InProgress;
        // Just await the load here.
        // Since I don't know the type of your _files object
        // this code won't compile since List.Add() only takes one argument
        files.Add(file.Type, await file.Source.LoadRecords(file));
        file.FileLoadStatus = Enums.FileLoadStatus.Completed;
    }

    return files;
}

Mvc – How should the model notify changes to the controller in the MVC paradigm

The Model knowing about, or being dependent on the Controller or View is not normally a problem in MVC.

In MVC the controller and View depend on the Model. Thus the model has no need for any dependency on anything.

You can even go further and get rid of the View's dependency on the Model, by creating and populating it in the Controller. Which is standard for web applications.

These methods do give you a problem for the case where the Model updates outside of a Controller event. For example, lets say the model has a Time property which updates automatically to the system time every second.

In these cases you will wish to update the view without having a controller event. This can be achieved by a number of methods

Have the Controller or View raise a periodic event every second to update the view. eg a Timer object.
Have something check for or be triggered by the underlying cause of the Model change and call the controller. eg a database trigger.
Have the Model raise an Event when the event happens and have the Controller and/or view bind to this event. eg Model.OnTimeUpdate

Obviously the best solution is to avoid these types of uncaused changes in your Model. Usually there is a cause of the change, and you can route that cause through a controller, thus capturing the event and removing or exposing a dependency of your Model at the same time.

MVVM - Model View ViewModel takes this further by Binding the View to events raised by the ViewModel and vice versa. This may suggest extra Events be added to the Model in order to further leverage this pattern, but such events are by no means required, nor do they require any dependencies be added to the model.