Is returning a Task violating the CQS-principle?
Asked Answered
A

3

6

So, if I write an async command, will that inevitably break the CQS-principle?

Angeliaangelic answered 23/11, 2015 at 14:56 Comment(2)
async void still has it's usage in fire and forget scenarios. Where the calling method does not care about the result/when it completesTightwad
@William, I'd say that async void has its uses in fire-and-forget scenarios that cannot be easily re-engineered to return Task. If you can have it return Task and have that task examined for error conditions which are at the very least logged, then it would be an improvement. "Never return void" is good advice, because it's only advice it's not worth following when it's advice it's impossible to follow.Gisela
G
6

At the level of considering what you want to know (a query) or do (a command) then Task<T> gives you data and hence is correct for a query and Task does not and hence is correct for a command. ("return void" is the language-specific way for some langauges to express "do not return data").

At the level below that, in which you are considering the mechanism by which asynchronous operations are managed, then you always want to have information about the state of the asynchronous operation and so always want some sort of task object. That is not the level to consider command-query separation.

Comparably, if a .NET method called into a COM method it would be calling into code that always returned a value indicating success or failure. That is just an implementation detail of how exception-handling happens in that particular technology. It's either vital or irrelevant to think about this depending on the level you are working at. Task is an implementation detail of how task-based asynchronous programming works. It's either vital or irrelevant to think about this depending on the level you are working at.

The level at which you need to think about "is this a command or a query", Task is an implementation-detail about how you get void.

Gisela answered 23/11, 2015 at 15:23 Comment(0)
A
9

When dealing with async Task represents void and Task<T> represents "a result". So no, it does not violate CQS you just need to think of Task as void.

Archean answered 23/11, 2015 at 15:3 Comment(0)
G
6

At the level of considering what you want to know (a query) or do (a command) then Task<T> gives you data and hence is correct for a query and Task does not and hence is correct for a command. ("return void" is the language-specific way for some langauges to express "do not return data").

At the level below that, in which you are considering the mechanism by which asynchronous operations are managed, then you always want to have information about the state of the asynchronous operation and so always want some sort of task object. That is not the level to consider command-query separation.

Comparably, if a .NET method called into a COM method it would be calling into code that always returned a value indicating success or failure. That is just an implementation detail of how exception-handling happens in that particular technology. It's either vital or irrelevant to think about this depending on the level you are working at. Task is an implementation detail of how task-based asynchronous programming works. It's either vital or irrelevant to think about this depending on the level you are working at.

The level at which you need to think about "is this a command or a query", Task is an implementation-detail about how you get void.

Gisela answered 23/11, 2015 at 15:23 Comment(0)
R
3

From the article you are linking:

When converting from synchronous to asynchronous code, any method returning a type T becomes an async method returning Task<T>, and any method returning void becomes an async method returning Task.

Therefore returning Task (not Task<T>) translates to having a method returning void.

Redtop answered 23/11, 2015 at 15:12 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.