OutputCache például felhasználói szerepkör alapján

Az egyik legerősebb ASP.NET eszköz a generált HTML tartalom gyorsítótárazásának lehetősége: Az oldal (vagy modul) tetején elhelyezett OutputCache direktívával elérhetjük, hogy az oldal (vagy modul) generált HTML tartalma több percre vagy órára is a szerver memóriájában maradjon. Ezzel brutális terheléseket tudunk kiszolgálni. A megjelenítendő tartalomnak azonban néha változnia kell. Erre szolgál az OutputCache direktíva Duration attribútuma. Egyszerűen megadjuk, hogy hány másodpercenként frissüljön a cache és kész…

A cache-elt tartalomnak azonban nem csak az idővel kell változnia! Gyakran egyidőben többféle cache-elt kimenetre is szükségünk lehet: egyre az adminnak (admin-gombokkal) és egyre a többieknek (admin-gombok nélkül). Vagy valami más alapján, de különbséget szeretnénk tenni. Az OutputCache direktíva VaryByParam attribútumával beállíthatunk néhány szempontot, ami szerint külön-külön gyorsítótárazzon az ASP.NET motor.

De mi van akkor, ha valamilyen szempontot a VaryByParam nem támogat? És gyakran ez a helyzet: például a felhasználó szerepköre alapján a VaryByParam nem tud különbséget tenni (pedig milyen jó lenne egy VaryByRole, vagy ilyesmi). Ekkor saját szempont-támogatást kell megvalósítanunk.

Nézzük hogyan megy ez:

1. Lássuk el az OutputCache direktívát egy VaryByCustom attribútummal, és adjunk neki valami egyedi értéket. Figyelem, ilyenkor sajnos kötelesek vagyuk a VaryByParam-ot is használni – állítsuk none értékűre.

    <%@ OutputCache Duration="600" VaryByCustom="MSDNKKRoleManagement" VaryByParam="none" %>

2. Csapjuk felül az alkalmazás GetVaryByCustomString( HttpContext context, string custom ) eseményét. Ezt praktikusan a global.asax-ban tudjuk megtenni. A metódus célja, hogy saját szempontjaink szerint tudjunk az ASP.NET motornak cache-kulcsot visszaadni. Az azonos kulcsra képződő dolgoknál ugyanaz lesz lecache-elve, a más kulcsúaknál más.

    public override string GetVaryByCustomString( HttpContext context, string custom )
    {
        // a sajat szempont figyelembevetele
        if( custom == "MSDNKKRoleManagement" )
        {
            // mas cache-kulcsot adok vissza az adminoknak
            if( context.User.IsInRole( "admin" ) )
                return "admin";
            // megint mast a power usereknek
            if( context.User.IsInRole( "poweruser" ) )
                return "poweruser";
    
            // es a tobbiek null-t kapnak
            return null;
                
        }
        // minden mas szempont mukodjon ugy, mint eddig
        else
        {
            return base.GetVaryByCustomString( context, custom );
        }
    }
    

 

A fenti kód mintájára szabadon kombinálhatunk. Olyan szempontok alapján gyorsítótáraztatunk az ASP.NET motorral, ami alapján nem szégyellünk. Ha például az aktuális felhasználó összes szerepkörét figyelembe szeretnénk venni, akkor adjuk vissza azok listáját rendezve és összefűzve. Nyilván vannak ennél jobb megoldások is, például ID lista, de a koncepció ugyanaz: Egyedi cache-kulcsot az azonosan cachelendő dolgok csoportjainak!



Dávid Zoltán

Dávid Zoltán Mérnök Informatikusként végeztem a BME-n, jelenleg webfejlesztéssel és gépi tanulással foglalkozom.

2009.02.19. 18:35:53 | Permalink | Hozzászólások: 0 | Tárgyszavak: , ,


  • Az IIS 7 szkriptelése: appcmd

    Balássy György (MS RD, ASP.NET MVP, MCTS) Webkiszolgálók üzemeltetésénél különösen fontos szempont a rendszergazdai feladatok automatizálhatósága, azaz a programozhatóság, melynek legegyszerűbb változata a parancssori szkriptelés. Az Internet Information Services 7 erre a problémára több megoldást is nyújt: programozottan WMI interfészen, a .NET-es Microsoft.Web.Administration névtéren vagy COM objektumokon keresztül kezelhetjük a kiszolgálót, parancssorból pedig PowerShellből vagy az AppCmd segédprogram segítségével. Tovább »
  • Lopjunk sütit a böngészőtől

    Balássy György (MS RD, ASP.NET MVP, MCTS) Egy .NET-es alkalmazásból a WebRequest osztály segítségével bármikor indíthatunk HTTP kéréseket egy weboldal felé. Ha a weboldal bejelentkezést igényel, akkor a webalkalmazás a szokásos módon cookie-k segítségével fogja megoldani az állapotkezelést, és a kliensre hárul a feladat, hogy a cookie-t minden kérésnél visszaküldje a szerverre. Ha a felhasználó böngészőből és a kliens alkalmazásból is eléri az alkalmazást, akkor sajnos kétszer kell bejelentkeznie, amire csak az lehet a megoldás, ha képesek vagyunk a böngésző által eltárolt sütit megszerezni. Tovább »


Írja meg Ön is véleményét!


Hozzászólásokat csak regisztrált, bejelentkezett felhasználóktól tudunk elfogadni!

Hozzászólások