Asinhronija reālā laikā ar ASP.NET MVC

Pielietojuma modeļi

Saziņa reāllaikā kļūst par nepieciešamību tīmekļa lietojumprogrammās, kuras pašlaik tiek veidotas, aiz tām vietnēm, kurās bija desmitiem lapu katrai lietotāja darbībai, tagad viss griežas ap vienas lapas lietojumprogrammām un tās spēju būt dinamiskam un asinhroni.
Tas liek mums izstrādāt paņēmienus, kas ļauj reālā laikā pieņemt un iegūt informāciju no lietojumprogrammā apstrādātajiem datiem, tāpēc mums jāzina pamatmetodes, kas ļauj mums veikt šīs pieejas.
Šajā sadaļā mēs redzēsim dažus paņēmienus, kā iegūt informāciju reālā laikā, tas ir, sasniegt asinhronijas stāvokli, neatkarīgi no lietotāja darbībām, lai serveris nosūtītu datus klientam.
klasisks modelis lietojumprogramma ir tad, kad mūsu lapa gaida atbildi no servera, tādējādi tie paliek sinhronā stāvoklī, kas visus jaunos datus padara atkarīgus no darbībām, kuras lietotājs veic klienta slānī, tādēļ, ja vēlaties redzēt atjauninājumu veiciet darbību, kas atkārtoti ielādē lapu.
Asinhronais modelisOtrs modelis ir asinhronija AJAX Ja lapas sadaļas tiek atkārtoti ielādētas, mēs izvairāmies no jauna ielādēt visu dokumentu, tomēr mēs joprojām esam atkarīgi no pirmā notikuma, kad lietotājs veic kādu darbību.
Visbeidzot, mēs varam runāt par patiesu saziņu reāllaikā, kad informāciju sūta serveris neatkarīgi no lietotāja darbībām, lai gan tas izklausās sarežģīti, patiesībā tā nav, tās ir vienkārši dažādas metodes, kuras mēs varam izmantot, tāpēc mēs to darīsim apskatiet dažus no mums pieejamajiem:
Šī metode sastāv no sarunas simulācijas starp klientu un serveri, tādā veidā mēs varam periodiski atjaunināt datus, nepārtraucot lietotāja darbību, radot iespaidu, ka dati tiek stumti reālā laikā.
Lai to panāktu, tiek veikta zvanu kombinācija AJAX un funkciju taimeris () no JavascriptAr to mēs varam kontrolēt, kā un kad dati tiks iegūti, tā trūkums ir tas, ka mēs tērējam resursus, jo, ja pieprasījumu ir vairāk nekā iegūto datu, mēs pārmērīgi izmantosim serveri, kas var radīt veiktspējas problēmas.

Šī tehnika, pretēji iepriekšējai, nav sarunas simulācija un nav arī vairāku zvanu, bet mēs veicam vienu zvanu, bet tas ir ļoti garš, tas ir, tas ir tāpat kā krāna atvēršana un, kamēr ūdens tek, mēs gaidām lai kaut kas nokristu.
Šim nolūkam mēs saglabājam savienojumu ar serveri atvērtu, līdz tiek saņemta atbilde, tas ir nedaudz vairāk līdzīgs reālajam laikam, tomēr problēma ir tā, ka, ja savienojums ir ļoti garš, to var slēgt vai, iespējams, klients piekļūst no atrašanās vieta, kas savienojumus slēdz ļoti īsā laikā, tāpēc tā nav ļoti uzticama, turklāt, atverot daudzus šāda stila pavedienus, mēs varam izraisīt servera avāriju.

Mēs jau esam redzējuši dažus pamata paņēmienus, kā reālā laikā izveidot lietojumprogrammas ar asinhroniem elementiem, un līdz ar to esam iemācījušies arī to trūkumus, nākamajā daļā mēs redzēsim šī uzdevuma uzlabotās metodes.
Iepriekšējais1 lapa no 2NākamaisVai jums patika šī apmācība un palīdzējāt tai?Jūs varat apbalvot autoru, nospiežot šo pogu, lai sniegtu viņam pozitīvu punktu