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: , ,


  • Több vezérlő validálása kliens oldalon

    Balássy György (MS RD, ASP.NET MVP, MCTS) Gyakran előforduló feladat, hogy egy vezérlő értékét nem önmagában kell validálnunk, hanem más vezérlők értékével együtt kell érvényesnek lennie. Sajnos az ASP.NET beépített validátorai közül egyedül a CompareValidator képes erre, aminek azonban végesek a képességei. Szerver oldalon még könnyen megbirkózunk a feladattal, de hogyan oldjuk meg, hogy a kliens oldali validáló függvényünk bármelyik vezérlő értékének változása esetén lefusson? Tovább »
  • MOSS blobcache

    Balássy György (MS RD, ASP.NET MVP, MCTS) Aki ismeri az ASP.NET cache szolgáltatásait és tudja, hogy a SharePoint az ASP.NET-re épül, annak számára nem újdonság, hogy a SharePoint is támogatja az output cachinget és az object cachinget. Amit viszont nem tud az ASP.NET, de a SharePoint igen, az a blob cache. 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