C# Discussion Boards - CodeProject

29-Sep-21 10:21

I see a lot of tutorials and examples that define controller methods like this:

[HttpGet]
public async Task<IEnumerable<Book>> GetBooks()
{
    return await _bookRepository.Get();
}

[HttpGet("{id}")]
public async Task<ActionResult<Book>> GetBooks(int id)
{
    return await _bookRepository.Get(id);
}

In these examples, the method signature returns a Task so that the method is async.

But can I just do this in my front end?

private async void LoadBooks()
{
    List books = null;

    await Task.Run(() =>
    {
        books = _proxy.GetBooks()

    }).ContinueWith(x => 
    {
        Books = new List(books);
    });
}

Why make the controller methods return task and use await? Doesn't my front end code acheive that?

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

modified 29-Sep-21 17:47pm.

Advanced TypeScript Programming Projects

Pete O'Hanlon29-Sep-21 20:22

Pete O'Hanlon

29-Sep-21 20:22

The reason that you return Task from an async method rather than void relates to the fact that returning void consumes exceptions that are being thrown. If you return Task, you have the ability to handle the exception gracefully. As for your code sample, you don't need to add an await on a Task.Run to get the ContinueWith to happen. In fact, you should remove that await altogether - if you're manually running up a Task here, you don't need async/await constructs.

Kevin Marois30-Sep-21 4:24

30-Sep-21 4:24

If a controller method is returning Task or Task<t>, then my front end method would need to be async, correct?

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

Richard Deeming30-Sep-21 4:41

30-Sep-21 4:41

The async-ness of your front-end methods is unrelated to the async-ness of your controller methods. You can have an async front-end method calling a non-async controller method, or a non-async front-end method calling an async controller method.

The front-end code is making a network request. It doesn't know or care how that request was fulfilled. The server could be using a synchronous method, an async method, or waiting for a carrier-pigeon. The front-end just needs to wait for the response.

Having said that, your front-end method should always be async if possible. It's making a network request, so you don't want to block a thread waiting for that to complete.

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

Kevin Marois30-Sep-21 4:48

30-Sep-21 4:48

Richard Deeming wrote:
The async-ness of your front-end methods is unrelated to the async-ness of your controller methods. You can have an async front-end method calling a non-async controller method, or a non-async front-end method calling an async controller method.

OK, so when I try this:

private async void GetSomeData()
{
    var myData = await GiveSomeData();
}

private int GiveSomeData()
{
    return 10;
}

I get a compiler error because GiveSomeData doesn't return a Task. How then do you call asynchronously call a method like GiveSOmeData?

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

Richard Deeming30-Sep-21 5:05

30-Sep-21 5:05

Within the same process, you can only use await when you're calling something that returns an awaitable object. That typically means either a Task or a ValueTask.

Your question was about calling a Web API from some front-end code. Those are two completely separate processes, which communicate via a network request. They know nothing about each other. They could be written in completely different languages.

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

Kevin Marois30-Sep-21 5:20

30-Sep-21 5:20

I see. Thank you

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

Richard Deeming29-Sep-21 21:54

29-Sep-21 21:54

async is not really about multi-threading; it's about not blocking the current thread waiting for an external resource.

In your example, there are two external resources - the API, and the database.

The front-end call needs to use an async call to the API, since it's a network request which could take a while to run. You don't want your UI thread blocked whilst it's waiting for that request to complete.

The controller methods need to use async calls to the database, since that's potentially another network call, plus disk access, plus the time it takes the DBMS to parse and execute the query.

Think of it like a car trip. In the non-async world, your kids are in the back seat constantly asking "Are we there yet?" over and over again until you arrive. In the async world, your kids sit quietly watching a film on their phone, and wait for you to tell them once you've arrived. One of those options is extremely irritating. Smile | :)

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

Kevin Marois30-Sep-21 4:23

MakeGenericType/CreateInstance Object to underlying Type at run-time: why this works is driving me crazy

30-Sep-21 4:23

Thank you for clarifying.

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

BillWoodruff28-Sep-21 5:45

Re: MakeGenericType/CreateInstance Object to underlying Type at run-time: why this works is driving me crazy

28-Sep-21 5:45

Using MakeGenericType and Activator.CreateInstance() to make a generic Type at runtime returns an Object: to make a usable instance of that Object, you have to cast it to its "native" Type.

surprise: i stumbled across a way to get a usable instance of the Object ... without explicit casting ... by using 'dynamic'; example:

// type template
Type generic = typeof(Dictionary<,>);

// array of types to substitute for the type parameters of the generic Type
Type[] typeArgs = { typeof(string), typeof(string) };

// Create a Type object representing the constructed generic type.
Type newGenericType = generic.MakeGenericType(typeArgs);

dynamic instance = Activator.CreateInstance(newGenericType);

instance.Add("1", "2");

I am not sure, how, in this case, use of 'dynamic' works.

Appreciate your thoughts.

Note: afaik, no example of this technique occurs in any MS documentation.

«The mind is not a vessel to be filled but a fire to be kindled» Plutarch

Richard Deeming28-Sep-21 6:20

Re: MakeGenericType/CreateInstance Object to underlying Type at run-time: why this works is driving me crazy

28-Sep-21 6:20

dynamic uses late-binding. Behind the scenes, it will use reflection to find and invoke the appropriate Add method on the run-time type of the object, with a suitable sprinkling of call-site caching to improve performance.

Simon Cooper published a series of blog posts on that topic back in 2012:
Inside the DLR - Callsites - Simple Talk[^]
Inside the DLR - Callsite binders - Simple Talk[^]
Inside the DLR - Invoking methods - Simple Talk[^]

NB: For the generic collections, you can probably avoid the DLR overhead by using the non-generic interfaces instead:

Type unboundType = typeof(Dictionary<,>);
Type[] typeArgs = { typeof(string), typeof(string) };
Type constructedType = generic.MakeGenericType(typeArgs);

IDictionary instance = (IDictionary)Activator.CreateInstance(constructedType);
instance.Add("1", "2");

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

BillWoodruff28-Sep-21 9:47

Re: MakeGenericType/CreateInstance Object to underlying Type at run-time: why this works is driving me crazy

28-Sep-21 9:47

Thank you ! Your example of using the unbound Type is very interesting.

«The mind is not a vessel to be filled but a fire to be kindled» Plutarch

OriginalGriff28-Sep-21 6:30

OriginalGriff

28-Sep-21 6:30

Dynamic types skip all compile time checking in favour of runtime checking - that includes method names, return types, number of parameters, type of parameters, or even that the method exists at all.

So because the return value is declared as dynamic, the compiler doesn't care what you try to call - and at run time the checks are done and the right method is called.
Try it:

dynamic items = new List<string>();
items.Add("Hello");
items.Add("World");
Console.WriteLine(string.Join(" ", items));
items.FallOverAndDie();

Will give you:

Hello World
Unhandled exception. Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: 'System.Collections.Generic.List<string>' does not contain a definition for 'FallOverAndDie'
   at CallSite.Target(Closure , CallSite , Object )
   at System.Dynamic.UpdateDelegates.UpdateAndExecuteVoid1[T0](CallSite site, T0 arg0)
   at Program.Main(String[] args)

Because the collection does not contain a FallOverAndDie method.

dynamic items = new List<string>();
items.Add("Hello");
items.Add("World");
Console.WriteLine(string.Join(" ", items));
items = new Dictionary<int, int>();
items.Add("Hello");
items.Add("World");
Console.WriteLine(string.Join(" ", items));

Will fail because the Dictionary class has no overload with just one parameter.

Personally, I'm still not convinced that adding dynamic to the language was a good idea - it seems too much like a way to move compile time errors to runtime and break strong typing ...

Re: MakeGenericType/CreateInstance Object to underlying Type at run-time: why this works is driving me crazy

BillWoodruff28-Sep-21 10:19

Re: MakeGenericType/CreateInstance Object to underlying Type at run-time: why this works is driving me crazy

28-Sep-21 10:19

Thanks !

OriginalGriff wrote:
Dynamic types skip all compile time checking in favour of runtime checking

I was aware of that, but, still felt there was some "spooky action at a distance" going on when it came to this specific type of Type creation.

i find the two examples that "fail" rather strange in this context because they contain rather obvious programming errors ... i think your point is the lack of compile checking, which is generally known by anyone who uses 'dynamic.

OriginalGriff wrote:
Personally, I'm still not convinced that adding dynamic to the language was a good idea - it seems too much like a way to move compile time errors to runtime and break strong typing ...

imho, that's a very interesting topic for debating what a supposedly strongly-typed language should expose for use by programmers.

Should it expose reflection, and dynamic, facilities ? Allow use of facilities that allow access to OS internals the way C# lets you use API's ? Expose Activator ? Expose a REPL facility ? i suppose an "extremist" might even oppose facilities like generics, and Linq, and extension methods.

i see use of 'dynamic as "dangerous," but useful when you absolutely have to have a "bag" of mixed Types and use of casting to interface is unwanted ... a whole lot better implementation than the now deprecated 'ArrayList.

The run-time creation and instantiation of generic Types seems valuable to me for creating object factories.

«The mind is not a vessel to be filled but a fire to be kindled» Plutarch

OriginalGriff28-Sep-21 10:40

OriginalGriff

28-Sep-21 10:40

I can see the intention, but I think that (just like var) it's too open to abuse.
With dynamic you can "get rid of all compiler errors" and provided your tests never reach the "bad code" you won't know until it fails in production. Which is against the whole ethos of C# and strong typing ...

It's a personal thing: I don't like production errors that I can catch as early as possible in the development process.

Re: MakeGenericType/CreateInstance Object to underlying Type at run-time: why this works is driving me crazy

BillWoodruff29-Sep-21 0:57