Biztos sokan láttatok már ilyen-olyan tutorial videókat, mint például ez is, ami az ASP.NET alkalmazások AJAXosítása kapcsán mindösszesen arról szól, hogy tegyünk bele mindent UpdatePanel-be, és készen is vagyunk. Kétségtelenül egyszerű, kétségtelenül működik is, de vajon tényleg ez a legjobb megoldás?
Ugye az egész mizéria onnan indul, hogy az ASP.NET odlalak alapvető tulajdonsága, hogy PostBackelnek. Fejlesztői szempontból elég jól tudunk élni ezzel, de felhasználói szempontból egy PostBack úgy néz ki, hogy egyrészt várni kell, másrészt villog is az oldal frissítéskor. Semmi gond, van megoldás, ne frissítsünk mindent, csak a szükséges területeket, szinkron kérés helyett pedig küldjünk aszinkron kérést a szerver felé, és oldjuk meg a kapott válasz alapján csak a megfelelő oldalterület újrarajzolását. Nem kell látványosan várni (mert ugye nem megy a böngésző alján a csík :) ), és nem is villog az oldal, mert nincs teljes oldalfrissítés, hiszen DOM-ban cseréljük ki az megfelelő oldalrészek tartalmát. Fejlesztői szempontból mi is ennek a legegyszerűbb módja? Vegyük elő az eszköztárunkból az UpdatePanelt, és keretezzük be vele a megfelelő oldalrészeket, majd állítsuk be a frissítési módjaikat Conditional-re. Pont erre van kitalálva: a benne generálódó postbackeket aszinkron kérésekké alakítja, és csak az általa határolt HTML tartalmat frissíti. Ezt tökéletesen el is végzi, használhatóságához és egyszerűségéhez kétség nem fér. Készen is vagyunk, éljen a "better user experience".
Mi a helyzet azonban teljesítménnyel? Tényleg a legjobb megoldást sikerült választani? Nem csak "szép" megoldás volna, hanem hatékony is? Csökkentettük is az adatforgalmat, tényleg csak azok az utazik föl a szerverre, amiknek kell? És az oldal életciklusa? Hogyan is történik a processzálás a szerveren? Ha elkezdjük ezeket a kérdéseket is firtatni, akkor rögtön rájövünk, hogy az UpdatePanellel is (mint oly sok mindennel) ésszel kell bánni.
Hagyományos ASP.NET postback esetén minden adat, ami az oldalon van, felutazik a szerverhez, beleértve a view state-et is, és leginkább a fránya viewstate az, aki miatt lassú lesz az oldalunk újratöltődése. Márpedig a viewstate elég gyakori az ASP.NET odlalainkon. Persze ki lehet kapcsolni, lehet csökkenteni a méretét, de megszűntetni nem tudjuk.
Mivel az UpdatePanel AJAX-ot használ, az AJAX vezérlők elvben pedig csak annyit küldenek fel a szeverre, amennyit szükséges, akkor "elvileg" rendben is vagyunk, nemde? Ha azonban megnézzük a konkrét HTTP forgalmat, akkor azt látjuk, hogy nem nyertünk túl sokat, legalább a kliens-szerver irányban biztosan nem. Ugyanis a teljes viewstate és egyéb adatok, amik normális esetben egy postbacknél jelen vannak, azok bizony az UpdatePanel-es aszinkron callback-nél most is ott csücsülnek; nagyjából ugyanaz megy fel aszinkron esetben is, mint szinkron postback esetén. Itt van a kutya elásva (dirty!!!), az UpdatePanel célja a használat egyszerűsége, mintsem a teljesítmény (legalábbis ami a kábelen átmegy)!!! Ehhez jön még az UpdatePanel által aszinkron módon meghívott oldal szerver oldali életciklusa. Az oldal lértejön, az oldalon lévő összes kontroll létrejön, majdnem a teljes életciklus lefut, de szerencsére már csak az UpdatePanelen belüli kontrollok esnek át a renderáláson. Ezek így együtt túl sok overheadet jelentenek az oldal egyetlen pici szeletének frissítéséhez. Az UpdatePanel használata alig csökkenti a szerver terhelését a hagyományos postbackhez képest. De legalább nem villog :).
Nem ennyire rossz a helyzet, megoldás természetesen létezik. Persze többet kell dolgozni vele, mint az UpdatePanel draganddroppolásával. Írhatunk WebMethod-okat (webszolgáltatásokat), és úgynevezett Page Method-okat (aspx markup-ba írt statikus metódus), és miután elláttuk őket a ScriptMethod attribútummal, kliens oldali kódból tudjuk hívni őket. Persze kézzel. És ez eredményt is kézzel kell feldolgoznunk JavaScriptben. Ez esetben tényleg csak az megy fel a szerverre, amit átadunk paraméterként a metódusnak, és az jön vissza, amit a szolgáltatás visszaküld, semmi fölösleg. Ennek ára van, kódot kell írnunk, ráadásul JavaScriptben. De ha fontos a teljesítmény is, nem csak a "nem villogás", akkor ezt az utat kell választanunk.