Halloj!

Skulle vilja cacha div saker i business lagret..

Finn det några funktioner för detta? vet att det finns massor i "asp" lagret men jag vill tex cacha användar logins och div små ”tabeller” för att slippa köra en fråga varje gång.

Har varit inne på någon typ av ”in memory” databas komponent men det känns som overkill för det jag vill uppnå...

Någon som har ideer?? (ibland så saknar jag mina gamla hederliga pekare)

Tackar

Hej!

En viktig arkitekturell princip jag alltid predikar för är tillståndslösa komponenter. Per definition alltså ingen cache i business layer, utan alla tillstånd hänvisas till databas och temporärt till klient. Pratar vi webblösning på MS-plattformen blir man alltså hänvisad till "asp"-lagret. Teknikerna för cache, session och viewstate känner du säkert till. Sedan kan man självklart hamna i dylika situationer som du nämner. "In memory" databas av något slag är nog rätta lösningen, overkill eller ej. Du kan ge Caching Application Block från MS patterns&practices en chans. Kanske kan ge idéer om hur man "wrappar" detta på ett hanterbart sätt. Rent arkitekturellt tycker jag ändå en sådan komponent hör till "asp"-lagret.

En viktig princip som jag alltid trycker på är "separation of concerns". I det här fallet skall man ställa sig frågan, bryr sig asp.net lagret hurvida datat är cachat eller inte? Svaret är oftast nej och då bör cachningen inte ligga där.

"Tillståndslösa komponenter" är ett begrepp som hamrats in pga WinDNA och distribuerade lösningar. Men det finns en gräns för hur tillståndslös en komponent skall vara. Att i "bussinesslagret", eller i servicelagret beroende på vilka designmodeller man nyttjar sig av, använda sig av en cache för att cacha flitigt använd data, räknas inte in till de scenarion där "tillståndslöshet" skall tas till sin spets. Ett populärt alternativ är att jobba med en L2 cache som ligger på DAL-nivå för att bara hämta de objekt som inte redan är inlästa.

Vad gäller teknikval så går det utmärkt att använda sig av ASP.NET's cachningsmekanism i sitt service layer, vill man ha en något enklare modell så kan man alltid spara värden i en statisk deladad kollektion. Läs mer på: http://www.lowendahl.net/showShout.aspx?id=16 och http://www.lowendahl.net/showShout.aspx?id=21

Använd System.Web.Caching!
Det går bra även utanför web-applikationer.
Och om dina komponenter körs på samma maskin är det ju normalt
sett så att de körs av IIS-processen ändå.

"Separation of concerns" är en princip som jag gärna skriver under på. Begreppet "asp-lagret" blev väl tyvärr aningen missvissande. Jag refererar istället till MS referensarkitektur. Jag håller med om att UI inte bryr sig om huruvida cachat eller ej. En dylik cachningskomponent skulle kategoriseras som en sk "cross-cutting concern". Denna refereras lämpligen av en komponent av typen "UI Process" och kan därmed vara återanvändbar för andra UIs.

Denna separation är givetvis applicerbar även om man flyttar mekanismen till service layer, även om jag skulle välja ovanstående.

Ingen arkitektur är bra i största allmänhet, utan endast utifrån det krav som ställs på den i varje specifikt fall. Därför håller jag med om att det är dumt att driva olika teser till sin spets. Skall man ändå generalisera vill jag nog ändå hävda att "tillståndslösa komponenter" är en bra princip även i generationen efter WinDNA.

Tackar för all input!

MS artiklarna patterns&practices ser klar intressanta ut och är nog den väg som hade känts “snyggast” att gå. Men har inte riktigt tid sätta mig in i dem :(
Efter som jag hur som blir beroende av en IIS för applikationen så löser jag det via System.Web.HttpRuntime.Cache.

Hade ingen aning om att jag kunde access ASP.Net cachen från "andra" project :)

För mig känns det rätt att denna cache finns i, eller snarare under bl efter som alla funktioner där kräver en påloggad session/behörighet för att köras.

Tackar!