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


  • Amikor az UpdatePanel nem működik

    Dávid Zoltán Egyik webalkalmazás kezdőlapján több (három) lapozható lista is van. Mindegyiket LinkView-val valósítottuk meg. Felmerült az igény, hogy ezek a listák egymástól és az oldaltól függetlenül, aszinkron módon lapozhatóak legyenek. Elvileg erre való az UpdatePanel. Mindhárom listát be is burkoltam egy-egy UpdatePanelbe, ekkor jött a meglepetés: két lista szépen az UpdatePanelen belül lapozódott csak, míg a harmadik minden esetben teljes postbacket csinált és újratöltötte a teljes oldalt. Kicsit mérgelődtem és kattintgattam, ezalatt “elromlott” egy újabb lista is: így már kettőből csak egy volt hajlandó aszinkron újratöltődésre. Mindeközben a TFS-ben az oldalak ID-talanítása... Tovább »
  • Az ASP.NET, a LINQ és a Tranzakció

    Dávid Zoltán LINQ2SQL-t használunk ASP.NET projektben. A LINQ-hez tartozó DataContextet szerettük volna egy olyan változóban tárolni, ami több helyről is elérhető. Erre azért van szükség, mert ha tranzakcióban több műveletet hajtasz végre, akkor tanácsos csak egyetlen DataContext példányt használni (különben elosztott tranzakció indul, annak minden nyűgével). Egy dologra kell ilyenkor figyelni: a DataContext nem állapotmentes, úgyhogy nem szabad felhasználók között passzolgatni. Ebből következik, hogy nem lehet static... 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