Programiranje

Najboljše prakse v .Net asinhronem programiranju

Asinhrono programiranje vam omogoča izvajanje I / O operacij, ki zahtevajo veliko sredstev, ne da bi vam bilo treba blokirati glavno ali izvršilno nit aplikacije. Čeprav je koristen in na videz enostaven za izvedbo, ima veliko zapletenosti in tveganj. Potencialna tveganja, povezana z asinhronim programiranjem, zlasti z napačno uporabo asinhronega programiranja z neupoštevanjem priporočenih praks, vključujejo zastoje, zrušitve procesov in celo počasno delovanje. Prav tako morate biti usposobljeni za pisanje in razhroščevanje asinkre kode.

Izogibajte se vrnitvi void type v async metodah

Metoda v C # je asinhrona metoda z uporabo ključne besede async v podpisu metode. V asinhronski metodi imate lahko eno ali več čakajočih ključnih besed. Ključna beseda await se uporablja za označevanje točke prekinitve. Async metoda v C # ima lahko katero koli od teh vrst vrnitev: Task, Task in void. Ključna beseda "await" se uporablja v asinhroni metodi, da obvesti prevajalnika, da ima metoda lahko točko začasne ustavitve in nadaljevanja.

Upoštevajte, da je pri uporabi TPL enakovredna vrnitev praznine v TPL asinh. Naloga. Zavedati se morate, da async void je in se sme uporabljati samo za async dogodke. Če jo uporabljate kje drugje, bi naleteli na napake. Z drugimi besedami, asinhronska metoda, ki ima kot vrnitev ničnost, ni priporočljiva. ker metode async, ki vrnejo void, imajo drugačno semantiko, ko delate z izjemami v svoji aplikaciji.

Ko pride do izjeme v asinhronski metodi, ki ima vrnjeni tip Opravilo ali Opravilo, se objekt izjeme shrani znotraj predmeta Opravilo. Nasprotno, če imate asinhronsko metodo z vrnitvijo tipa void, ni povezan noben objekt Task. Takšne izjeme se pojavljajo v SynchronizationContext, ki je bil aktiven v času, ko je bila klicana asinhrona metoda. Z drugimi besedami, z obdelavami izjem, zapisanimi v asinhroni metodi, ne morete obvladovati izjem, ustvarjenih znotraj metode async void. Zaradi te razlike v semantiki ravnanja z napakami je težko preizkusiti tudi asinhrične metode, ki imajo vrnjeno void. V vednost razred imen SynchronizationContext v imenskem prostoru System.Threading predstavlja kontekst sinhronizacije v .Netu in vam pomaga, da opravilo postavite v čakalno vrsto v drug kontekst.

To ponazarja naslednji seznam kod. Imate dve metodi, in sicer Test in TestAsync, slednja pa vrže izjemo.

javni razred AsyncDemo

   {

preizkus javne praznine ()

       {

poskusite

           {

TestAsync ();

           }

ulov (izjema ex)

           {

Console.WriteLine (npr. Sporočilo);

           }

       }

zasebna async void TestAsync ()

       {

vrzi novo izjemo ("To je sporočilo o napaki");

       }

   }

Tukaj je opisano, kako lahko ustvarite primerek razreda AsyncDemo in prikličete preskusno metodo.

statična praznina Main (string [] args)

       {

AsyncDemo obj = novo AsyncDemo ();

obj.Test ();

Console.Read ();

       }

Preskusna metoda pokliče metodo TestAsync in klic je ovit v blok try-catch z namenom obdelave izjeme, vržene znotraj metode TestAsync. Vendar izjema, vržena znotraj metode TestAsync, ne bo nikoli zajeta, tj. Obdelana znotraj metode klicatelja Test.

Izogibajte se mešanju asinhrone in sinhrone kode

Nikoli ne smete imeti kombinacije sinhrone in asinhrone kode. Slaba praksa programiranja je, da blokirate asinhrono kodo tako, da kličete Task.Wait ali Task.Result. Priporočam uporabo async kode od konca do konca - to je najvarnejši način, da se izognete napakam, ki se prikradejo.

Zastojem se lahko izognete z uporabo.ConfigureAwait (continueOnCapturedContext: false) kadar koli pokličete na čakanje. Če tega ne uporabite, bi metoda async blokirala na mestu, kjer je bil poklican await. V tem primeru samo obvestite natakarja, naj ne zajame trenutnega konteksta. Rekel bi, da je dobra praksa, da uporabite .ConfigureAwait (false), razen če imate poseben razlog, da je ne uporabite.

O asinhronem programiranju bi razpravljal več v svojih prihodnjih objavah v blogu tukaj. Za več informacij o najboljših praksah v asinhronem programiranju si lahko ogledate odličen članek Stephena Clearyja na MSDN.