Timeline for How to avoid pollution of logic with lazy-loaded async properties
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 28, 2016 at 16:32 | comment | added | Shadow | @PeriataBreatta I think that You do not really understand idea of async/await. Take a look there - msdn.microsoft.com/en-us/magazine/dn802603.aspx if your application is database bound it may scale much better without any (additional) concurrency. | |
| Sep 27, 2016 at 7:24 | comment | added | Periata Breatta | @user2029276 - hmm. when I've had that kind of problem I've taken the implementation out of the web server into a standalone service and then used a push notification system to let the client know when the request is finished, but I guess that C#'s async makes it easier to do this in the web server now, so maybe your way is better for this. Unfortunately, what you're looking it is as far as I can see necessary complexity for solving this problem, which is why I would have suggested simplifying by avoiding the concurrency if possible. It's unfortunate that you can't... :( | |
| Sep 26, 2016 at 10:39 | comment | added | Shadow | @PeriataBreatta My webapp connects to many databases and 3rd party webservices. Also some of my clients run it on old hardware (even laptops). Some of these 3rd party webservices are poorly writen and take ages to respond, so I already need async code in my application. I would like to go along and make other not-yet-written code async, because why not? Implementation problems are highlighted here, and I am seeking solution for them. | |
| Sep 23, 2016 at 4:57 | comment | added | Periata Breatta | @user2029276 - I wouldn't say "of course". You're talking about an exceptionally high performance requirement. You're talking about performance requirements that aren't actually met by most of the most popular web sites on the planet. Realistically, what you're describing is only necessary if you're serving hundreds of requests per second and can't afford to scale horizontally to more servers. Keeping the implementation simple is usually much more important than the absolute performance of a single server. | |
| Sep 22, 2016 at 22:21 | comment | added | Shadow | @PeriataBreatta Yes, of course. | |
| Sep 19, 2016 at 17:38 | comment | added | Periata Breatta | @user2029276 - Why does the web server need to do that, though? I've been writing web applications that wait for db results rather than returning earlier since 1997 and have never once needed to do such a thing. Are you really working on a system that's so performance critical that threads blocking for database access aren't acceptable? | |
| Sep 17, 2016 at 9:24 | comment | added | Shadow | @Periata It needs to be async so webserver may use thread for other requests while waiting for database to return data. | |
| Sep 16, 2016 at 15:01 | comment | added | Periata Breatta | @user2029276 - I have written many many applications where hitting the database does not mean the method that does it must be asynchronous. It is entirely possible (and in many cases advisable) to simply write a method that waits for the database call to finish before returning rather than returning a Lazy<> or similar stub. Indeed, I'd usually consider that default behaviour. The relevant question is, why does the client need to be able to asynchronously wait for the database call to return? | |
| Sep 16, 2016 at 11:53 | comment | added | Shadow |
In my example method LoadPayer returns Task<Payer>, and it needs to be async (and method), as it hits database.
|
|
| Sep 16, 2016 at 11:49 | comment | added | Peter Taylor |
It could do, if you don't care about thread safety and you're forced to use an old version of the framework. But if you have .Net 4.0 then Lazy<T> was added for a reason.
|
|
| Sep 16, 2016 at 9:16 | history | answered | Bernhard Hiller | CC BY-SA 3.0 |