Atstsky hell and asynchronous asynchrony

Hello, Artem Korneev, you wrote: AK> And so. It is all works, but the result seems to me unduly difficult. Especially I am am confused here with this ladder from async/await: AK> AK> await this.retryPolicy. ExecuteAndCaptureAsync (AK> async () => AK> await Task. Run (AK> async () => response = await callback. Invoke (http))); AK> And who forces to use you these all async / await? await this.retryPolicy. ExecuteAndCaptureAsync (() => Task. Run (() => response = callback. Invoke (http)));

Hello, Sinix, you wrote: S> Hello, Artem Korneev, you wrote: AK>> It would be desirable to rewrite all it to more clear type. S> to use await in each method on a call chain it is absolutely optional. S> S> public async Task InvokeHttpCall (Func <HttpClient, Task <HttpResponseMessage>> callback) S> {S> using (var httpClient = new HttpClient ()) S> {S> HttpResponseMessage response = null; S> var http = httpClient; S> await this.retryPolicy. ExecuteAndCaptureAsync (() => S> callback. Invoke (http).ContinueWith (t => response = t. Result)); S>} S>} S> S> And if a companion author Polly would read  the code would look as S> S> response = await this.retryPolicy. ExecuteAndCaptureAsync (() => callback. Invoke (http)).Result; S> S> I on your place would get issue on this business. callback. Invoke (http) <- what for Invoke??? response = await this.retryPolicy. ExecuteAndCaptureAsync (() => callback (http)).Result;

Hello, Artem Korneev, you wrote: AK> AK> public async Task InvokeHttpCall (Func <HttpClient, Task <HttpResponseMessage>> callback) AK> {AK> using (var httpClient = new HttpClient ()) AK> {AK> HttpResponseMessage response = null; AK> var http = httpClient; AK> await this.retryPolicy. ExecuteAndCaptureAsync (AK> async () => AK> await Task. Run (AK> async () => response = await callback. Invoke (http))); AK>} AK>} AK> In your code there is one jamb not concerning to async. httpclient should be static private static HttpClient httpClient = new HttpClient (); YOU'RE USING HTTPCLIENT WRONG AND IT IS DESTABILIZING YOUR SOFTWARE

Hello, ifle, you wrote: I> In your code there is one jamb not concerning to async. httpclient should be static does not approach on usage conditions. This RestClient is used in multi-tenant cloudy service, i.e. there two serial requests can come from different users of the different organizations. In it HttpClient there is field DefaultRequestHeaders where are exposed  authorizations. I.e. making static, we break at once all authentification. All is used it rather rarely (at least, while) so problems because of re-creation of object HttpClient are not present. But for thanks information.

Hello, Artem Korneev, you wrote: On RestSharp for needs looked?

Hello, Tom, you wrote: Tom> Esi eventually all the same at all of us is reduced to the synchronous code on which   generally, it will be synchronously possible directly in ExecuteAndCaptureAsync the delegate to transfer which to be fulfilled callback launches the new task, it it is necessary to wait and push result in response. And Task. Run here generally the superfluous.

Hello, Sharov, you wrote: S> On RestSharp for needs looked? No, did not look. The REST-client was easier for implementing, than to search for the ready. Now looked on RestSharp, syntax is not pleasant to me. var request = new RestRequest ("resource / {id}", Method. POST);... IRestResponse response = client. Execute (request); var content = response. Content; at me all is enveloped in  and HTTP-methods have appropriate wrappers in class RestClient, i.e. I cause it somehow so: var result = restClient. Get <MyDataType> ("http://localhost") Also I receive in the answer already deserialised object.

Hello, SergASh, you wrote: SAS> That for  the such? The reference can be asked? Was specific on  anything fresh Task-based Asynchronous Pattern (TAP) did not quit, but here a reality and it is not required. Enough the general reasons from FDG book: Framework Design Principle Frameworks must be designed starting from a set of usage scenarios and code samples implementing these scenarios. If it is not clear, about what speech -  on a detailed explanation. On a specific example://1. We have an action which something returns var result = await GetResultAsync (someParams);//2. We want to launch this action in any context using (var contex = GetCaptureContext (someParams)) {var result = await GetResultAsync (someParams);} //3. We want to control calls in a context, for example, to launch the code some times.//we Turn action in the delegate, we receive var result = await retryPolicy. ExecuteAndCaptureAsync (() => GetResultAsync (someParams)));//4. We want to return except the result something else, for example, an amount of iterations var executeResult = await retryPolicy. ExecuteAndCaptureAsync (() => GetResultAsync (someParams))); var result = executeResult. Result; Sense such: each short step allows to solve __ a problem and in itself does not create the new. About with small steps it to trace very easily and it is not required to spring back to specify, whether forgot that. An elephant eat on slices. If on this principle to hammer and threaten on an elephant entirely the today's example turns out: the code is able everything, except the initial scenario That the most insulting, here during this moment people __ do not try to stop and look for the moment to which all went not so. Instead a problem mask new crutches and so until the volume of crutches does not outgrow volume of actually useful code on the order.

Hello, Sinix, you wrote: S> And if a companion author Polly would read  the code would look as S> S> response = await this.retryPolicy. ExecuteAndCaptureAsync (() => callback. Invoke (http)).Result; S> await together with Result?