Cacha data via ObjectDataSource (VB)

av Scott Mitchell

Ladda ned PDF

Cachelagring kan innebära skillnaden mellan ett långsamt och ett snabbt webbprogram. Den här handledningen är den första av fyra som tar en detaljerad titt på cachelagring i ASP.NET. Lär dig de viktigaste begreppen för cachelagring och hur du tillämpar cachelagring på presentationsskiktet via ObjectDataSource-kontrollen.

Inledning

Inom datavetenskap är cachelagring processen att ta data eller information som är dyr att hämta och lagra en kopia av den på en plats som är snabbare att komma åt. För datadrivna program förbrukar stora och komplexa frågor vanligtvis större delen av programmets körningstid. Ett sådant programs prestanda kan därför ofta förbättras genom att lagra resultatet av dyra databasfrågor i programmets minne.

ASP.NET 2.0 erbjuder en mängd olika alternativ för cachelagring. En webbsida eller användarkontrolls genererade markering kan cachelagras via cachelagring av utdata. Kontrollerna ObjectDataSource och SqlDataSource tillhandahåller även cachelagringsfunktioner, vilket gör att data kan cachelagras på kontrollnivå. Och ASP.NET datacache har ett omfattande cachelagrings-API som gör det möjligt för sidutvecklare att programmatiskt cachelagra objekt. I den här självstudien och de tre kommande ska vi undersöka hur du använder Cachelagringsfunktionerna för ObjectDataSource samt datacachen. Vi ska också utforska hur du cachelagrar programomfattande data vid start och hur du håller cachelagrade data fräscha med hjälp av SQL-cacheberoenden. Dessa handledningar behandlar inte cachelagring av utdata. En detaljerad titt på cachelagring av utdata finns i Cachelagring av utdata i ASP.NET 2.0.

Cachelagring kan tillämpas på valfri plats i arkitekturen, från dataåtkomstlagret upp till presentationslagret. I den här självstudien ska vi titta på hur du tillämpar cachelagring på presentationslagret via ObjectDataSource-kontrollen. I nästa handledning kommer vi att undersöka hur man cachelagrar data i affärslogiklagret.

Nyckelcachekoncept

Cachelagring kan avsevärt förbättra ett programs övergripande prestanda och skalbarhet genom att ta data som är dyra att generera och lagra en kopia av dem på en plats som kan nås mer effektivt. Eftersom cachen bara innehåller en kopia av faktiska, underliggande data kan den bli inaktuell eller inaktuell om underliggande data ändras. För att bekämpa detta kan en sidutvecklare ange kriterier för vilket cacheobjektet ska tas bort från cacheminnet med hjälp av något av följande:

• Tidsbaserade kriterier ett objekt kan läggas till i cacheminnet under en absolut eller glidande varaktighet. En sidutvecklare kan till exempel ange en varaktighet på till exempel 60 sekunder. Med en absolut varaktighet avlägsnas det cachelagrade objektet 60 sekunder efter att det lades till i cacheminnet, oavsett hur ofta det användes. Med en glidande varaktighet avlägsnas det cachelagrade objektet 60 sekunder efter den senaste åtkomsten.
• Beroendebaserade kriterier ett beroende kan associeras med ett objekt när det läggs till i cacheminnet. När objektets beroende ändras tas det bort från cacheminnet. Beroendet kan vara en fil, ett annat cacheobjekt eller en kombination av de två. ASP.NET 2.0 tillåter också SQL-cacheberoenden, vilket gör det möjligt för utvecklare att lägga till ett objekt i cacheminnet och få det borttaget när underliggande databasdata ändras. Vi kommer att gå igenom SQL Cache-beroenden i den kommande genomgången Använda SQL Cache-beroenden.

Oavsett vilka borttagningsvillkor som angetts kan ett objekt i cacheminnet rensas innan de tidsbaserade eller beroendebaserade kriterierna har uppfyllts. Om cachen har nått sin kapacitet måste befintliga objekt tas bort innan nya kan läggas till. När du programmatiskt arbetar med cachelagrade data är det därför viktigt att du alltid antar att cachelagrade data kanske inte finns. Vi ska titta på mönstret som ska användas när du kommer åt data från cachen programmatiskt i nästa självstudie, Cachelagring av data i arkitekturen.

Cachelagring ger ett ekonomiskt sätt att pressa mer prestanda från ett program. Som Steven Smith formulerar i sin artikel ASP.NET Cachelagring: Tekniker och bästa praxis:

Cachelagring kan vara ett bra sätt att få tillräckligt med prestanda utan att kräva mycket tid och analys. Minnet är billigt, så om du kan få den prestanda du behöver genom att cachelagra utdata i 30 sekunder i stället för att tillbringa en dag eller en vecka med att försöka optimera din kod eller databas, gör cachelagringslösningen (förutsatt att 30 sekunder gamla data är ok) och gå vidare. Så småningom kommer dålig design förmodligen att komma ikapp dig, så naturligtvis bör du försöka utforma dina program korrekt. Men om du bara behöver få tillräckligt med prestanda idag kan cachelagring vara en utmärkt [metod], att köpa dig tid att omstrukturera ditt program vid ett senare tillfälle när du har tid att göra det.

Cachelagring kan ge märkbara prestandaförbättringar, men det är inte tillämpligt i alla situationer, till exempel med program som använder realtidsdata och ofta uppdaterar, eller där till och med kortlivade inaktuella data är oacceptabla. Men för de flesta program bör cachelagring användas. Mer bakgrund om cachelagring i ASP.NET 2.0 finns i avsnittet Cachelagring för prestanda i snabbstartsguiderna ASP.NET 2.0.

Steg 1: Skapa cachelagringswebbsidor

Innan vi börjar utforska cachelagringsfunktionerna för ObjectDataSource ska vi först ta en stund att skapa de ASP.NET sidor i vårt webbplatsprojekt som vi behöver för den här självstudien och de tre kommande. Börja med att lägga till en ny mapp med namnet Caching. Lägg sedan till följande ASP.NET sidor i mappen och se till att associera varje sida med Site.master huvudsidan:

• Default.aspx
• ObjectDataSource.aspx
• FromTheArchitecture.aspx
• AtApplicationStartup.aspx
• SqlCacheDependencies.aspx

Bild 1: Lägg till ASP.NET-sidorna för Caching-Related-självstudierna

Precis som i de andra mapparna kommer Default.aspx i Caching-mappen att lista självstudierna i dess avsnitt. Kom ihåg att SectionLevelTutorialListing.ascx användarkontrollen innehåller den här funktionen. Lägg därför till den här användarkontrollen genom att Default.aspx dra den från Solution Explorer till sidans designvy.

Bild 2: Bild 2: Lägg till SectionLevelTutorialListing.ascx användarkontrollen Default.aspx i (Klicka om du vill visa en bild i full storlek)

Slutligen lägger du till dessa sidor som posteringar i Web.sitemap-filen. Mer specifikt lägger du till följande markering efter Arbeta med binära data <siteMapNode>:

<siteMapNode title="Caching" url="~/Caching/Default.aspx" 
    description="Learn how to use the caching features of ASP.NET 2.0.">
    <siteMapNode url="~/Caching/ObjectDataSource.aspx" 
        title="ObjectDataSource Caching" 
        description="Explore how to cache data directly from the 
            ObjectDataSource control." />
    <siteMapNode url="~/Caching/FromTheArchitecture.aspx" 
        title="Caching in the Architecture" 
        description="See how to cache data from within the 
            architecture." />
    <siteMapNode url="~/Caching/AtApplicationStartup.aspx" 
        title="Caching Data at Application Startup" 
        description="Learn how to cache expensive or infrequently-changing 
            queries at the start of the application." />
    <siteMapNode url="~/Caching/SqlCacheDependencies.aspx" 
        title="Using SQL Cache Dependencies" 
        description="Examine how to have data automatically expire from the 
            cache when its underlying database data is modified." />
</siteMapNode>

Efter att du har uppdaterat Web.sitemap, ta en stund att besöka självstudiewebbplatsen via en webbläsare. Menyn till vänster innehåller nu ämnen för handledningar om cachelagring.

Bild 3: Webbplatskartan innehåller nu poster för cachehandledningar

Steg 2: Visa en lista över produkter på en webbsida

I den här självstudien beskrivs hur du använder ObjectDataSource-kontrollens inbyggda cachelagringsfunktioner. Innan vi kan titta på de här funktionerna behöver vi dock först en sida att arbeta från. Nu ska vi skapa en webbsida som använder en GridView för att visa produktinformation som hämtats av en ObjectDataSource från ProductsBLL klassen.

Börja med att öppna sidan ObjectDataSource.aspx i Caching mappen. Dra en GridView från verktygslådan till designern, ange dess ID egenskap till Products, och från den smarta taggen väljer du att binda den till en ny ObjectDataSource-kontroll med namnet ProductsDataSource. Konfigurera ObjectDataSource så att den fungerar med ProductsBLL-klassen.

Konfigurera ObjectDataSource för att använda klassen ProductsBLL

Bild 4: Konfigurera ObjectDataSource att använda ProductsBLL klassen (Klicka om du vill visa en bild i full storlek)

För den här sidan ska vi skapa en redigerbar GridView så att vi kan undersöka vad som händer när data som cachelagras i ObjectDataSource ändras via GridView-gränssnittet. Lämna listrutan på fliken SELECT som standard, GetProducts(), men ändra det markerade objektet på fliken UPPDATERA till den UpdateProduct överlagring som accepterar productName, unitPriceoch productID som indataparametrar.

Bild 5: Ställ in fliken Uppdatera Drop-Down-listan till lämplig UpdateProduct överbelastning (Klicka för att visa bilden i full storlek)

Slutligen anger du listrutorna på flikarna "INSERT" och "DELETE" till "(Ingen)" och klickar på "Slutför". När du har slutfört guiden Konfigurera datakälla anger Visual Studio egenskapen ObjectDataSource till OldValuesParameterFormatStringoriginal_{0}. Som beskrivs i självstudiekursen En översikt över infogning, uppdatering och borttagning av data måste den här egenskapen tas bort från den deklarativa syntaxen eller återgå till standardvärdet , {0}för att vårt uppdateringsarbetsflöde ska kunna fortsätta utan fel.

När guiden är klar lägger Visual Studio dessutom till ett fält i GridView för vart och ett av produktdatafälten. Ta bort alla utom ProductName, CategoryNameoch UnitPrice BoundFields. Uppdatera sedan egenskaperna för HeaderText var och en av dessa BoundFields till Produkt, Kategori respektive Pris. Eftersom fältet ProductName krävs konverterar du BoundField till ett TemplateField och lägger till en RequiredFieldValidator i EditItemTemplate. På samma sätt konverterar UnitPrice du BoundField till ett TemplateField och lägger till en CompareValidator för att säkerställa att värdet som anges av användaren är ett giltigt valutavärde som är större än eller lika med noll. Förutom dessa ändringar kan du utföra estetiska ändringar, till exempel högerjustera UnitPrice värdet eller ange formateringen för UnitPrice texten i dess skrivskyddade gränssnitt och redigeringsgränssnitt.

Gör rutnätsvyn redigerbar genom att markera kryssrutan Aktivera redigering i GridViews smarta tagg. Markera också kryssrutorna Aktivera sidindelning och Aktivera sortering.

Bild 6: Aktivera Stöd för GridView för redigering, sortering och växling (Klicka om du vill visa en bild i full storlek)

När du har gjort dessa GridView-ändringar bör GridView och ObjectDataSources deklarativa markering se ut ungefär så här:

<asp:GridView ID="Products" runat="server" AutoGenerateColumns="False" 
    DataKeyNames="ProductID" DataSourceID="ProductsDataSource" 
    AllowPaging="True" AllowSorting="True">
    <Columns>
        <asp:CommandField ShowEditButton="True" />
        <asp:TemplateField HeaderText="Product" SortExpression="ProductName">
            <EditItemTemplate>
                <asp:TextBox ID="ProductName" runat="server" 
                    Text='<%# Bind("ProductName") %>'></asp:TextBox>
                <asp:RequiredFieldValidator 
                    ID="RequiredFieldValidator1" Display="Dynamic" 
                    ControlToValidate="ProductName" SetFocusOnError="True"
                    ErrorMessage="You must provide a name for the product."
                    runat="server">*</asp:RequiredFieldValidator>
            </EditItemTemplate>
            <ItemTemplate>
                <asp:Label ID="Label2" runat="server" 
                    Text='<%# Bind("ProductName") %>'></asp:Label>
            </ItemTemplate>
        </asp:TemplateField>
        <asp:BoundField DataField="CategoryName" HeaderText="Category" 
            ReadOnly="True" SortExpression="CategoryName" />
        <asp:TemplateField HeaderText="Price" SortExpression="UnitPrice">
            <EditItemTemplate>
                $<asp:TextBox ID="UnitPrice" runat="server" Columns="8" 
                    Text='<%# Bind("UnitPrice", "{0:N2}") %>'></asp:TextBox>
                <asp:CompareValidator ID="CompareValidator1"
                    ControlToValidate="UnitPrice" Display="Dynamic" 
                    ErrorMessage="You must enter a valid currency value with no 
                        currency symbols. Also, the value must be greater than 
                        or equal to zero."
                    Operator="GreaterThanEqual" SetFocusOnError="True" 
                    Type="Currency" runat="server" 
                    ValueToCompare="0">*</asp:CompareValidator>
            </EditItemTemplate>
            <ItemStyle HorizontalAlign="Right" />
            <ItemTemplate>
                <asp:Label ID="Label1" runat="server" 
                    Text='<%# Bind("UnitPrice", "{0:c}") %>' />
            </ItemTemplate>
        </asp:TemplateField>
    </Columns>
</asp:GridView>
<asp:ObjectDataSource ID="ProductsDataSource" runat="server"
    OldValuesParameterFormatString="{0}" SelectMethod="GetProducts" 
    TypeName="ProductsBLL" UpdateMethod="UpdateProduct">
    <UpdateParameters>
        <asp:Parameter Name="productName" Type="String" />
        <asp:Parameter Name="unitPrice" Type="Decimal" />
        <asp:Parameter Name="productID" Type="Int32" />
    </UpdateParameters>
</asp:ObjectDataSource>

Som bild 7 visar visar det redigerbara GridView namn, kategori och pris för var och en av produkterna i databasen. Ta en stund att testa sidans funktioner för att sortera resultaten, bläddra igenom dem och redigera en post.

Bild 7: Varje produkts namn, kategori och pris visas i en sorterbar, växlingsbar, redigerbar GridView (klicka om du vill visa en bild i full storlek)

Steg 3: Undersöka när ObjectDataSource begär data

Products GridView hämtar sina data som ska visas genom att Select anropa metoden för ProductsDataSource ObjectDataSource. Den här ObjectDataSource skapar en instans av klassen Affärslogiklagret ProductsBLL och anropar dess GetProducts() metod, som i sin tur anropar Dataåtkomstlagrets ProductsTableAdapterGetProducts() metod. DAL-metoden ansluter till Northwind-databasen och utfärdar den konfigurerade SELECT frågan. Dessa data returneras sedan till DAL, som paketerar dem i en NorthwindDataTable. DataTable-objektet returneras till BLL:n, som returnerar det till ObjectDataSource, som returnerar det till GridView. GridView skapar sedan ett GridViewRow objekt för varje DataRow i DataTable, och varje GridViewRow återges så småningom i HTML-koden som returneras till klienten och visas i besökarens webbläsare.

Den här händelsesekvensen inträffar varje gång GridView behöver binda till sina underliggande data. Det händer när sidan först besöks, när du flyttar från en sida med data till en annan, när du sorterar GridView eller när du ändrar GridView-data via dess inbyggda redigerings- eller borttagningsgränssnitt. Om GridView-vytillståndet är inaktiverat, kommer GridView att återställas på varje postback också. GridView kan också uttryckligen återgå till sina data genom att anropa dess DataBind() metod.

För att fullt ut uppskatta hur ofta data hämtas från databasen ska vi visa ett meddelande som anger när data hämtas på nytt. Lägg till en etikettwebbkontroll ovanför GridView med namnet ODSEvents. Rensa dess Text egenskap och ange dess EnableViewState egenskap till False. Under etiketten lägger du till en knappwebbkontroll och anger dess Text egenskap till Postback .

Bild 8: Lägg till en etikett och knapp på sidan ovanför GridView (Klicka om du vill visa en bild i full storlek)

Under arbetsflödet för dataåtkomst utlöses ObjectDataSource-händelsen Selecting innan det underliggande objektet skapas och dess konfigurerade metod anropas. Skapa en händelsehanterare för den här händelsen och lägg till följande kod:

Protected Sub ProductsDataSource_Selecting(sender As Object, _
    e As ObjectDataSourceSelectingEventArgs) _
    Handles ProductsDataSource.Selecting
    ODSEvents.Text = "-- Selecting event fired"
End Sub

Varje gång ObjectDataSource skickar en begäran till arkitekturen för data, visar etiketten texten "Selecting event fired".

Besök den här sidan i en webbläsare. När sidan först besöks visas texten Välj händelse som utlöses. Klicka på knappen Postback och observera att texten försvinner (förutsatt att egenskapen GridView är EnableViewState inställd på True, standardvärdet). Det beror på att GridView vid efteråterställning rekonstrueras från sitt visningstillstånd och därför inte vänder sig till ObjectDataSource för sina data. Sortering, sidbläddring eller redigering av data leder dock till att GridView kopplas om till sin datakälla, och därför visas texten "Selecting event fired" igen.

Bild 9: När GridView återbinds till sin datakälla utlöses en valhändelse (Klicka om du vill se bilden i full storlek)

Bild 10: Om du klickar på knappen Efteråterställning återskapas GridView från visningstillståndet (klicka om du vill visa en bild i full storlek)

Det kan verka slösaktigt att hämta databasdata varje gång data bläddras igenom eller sorteras. Eftersom vi använder standardsidindelning har ObjectDataSource hämtat alla poster när den första sidan visas. Även om GridView inte tillhandahåller stöd för sortering och paginering måste data hämtas från databasen varje gång sidan först besöks av någon användare (och vid varje återkoppling, om vytilståndet är inaktiverat). Men om GridView visar samma data för alla användare är dessa extra databasbegäranden överflödiga. Varför inte cachelagra resultaten som returneras från GetProducts() metoden och binda GridView till dessa cachelagrade resultat?

Steg 4: Cacha datan med hjälp av ObjectDataSource

Genom att bara ange några egenskaper kan ObjectDataSource konfigureras för att automatiskt cachelagras sina hämtade data i ASP.NET datacachen. I följande lista sammanfattas de cacherelaterade egenskaperna för ObjectDataSource:

• EnableCaching måste anges till True för att aktivera cachelagring. Standardvärdet är False.
• CacheDuration den tid i sekunder som data cachelagras. Standardvärdet är 0. ObjectDataSource cachelagrar endast data om EnableCaching är True och CacheDuration är inställt på ett värde som är större än noll.
• CacheExpirationPolicy kan anges till Absolute eller Sliding. Om Absolutecachelagrar ObjectDataSource sina hämtade data CacheDuration i sekunder. Om Slidingupphör data endast att gälla när de inte har använts på CacheDuration några sekunder. Standardvärdet är Absolute.
• CacheKeyDependency använder den här egenskapen för att associera ObjektDataSources cacheposter med ett befintligt cacheberoende. ObjectDataSources dataobjekt kan tas bort i förtid från cacheminnet genom att dess associerade CacheKeyDependency. Den här egenskapen används oftast för att associera ett SQL-cacheberoende med ObjectDataSource-cachen, ett ämne som vi kommer att utforska i framtiden självstudiekursen Använda SQL Cache Dependencies .

Låt oss konfigurera ProductsDataSource ObjectDataSource för att cachelagra sina data i 30 sekunder på en absolut skala. Ange egenskapen EnableCaching ObjectDataSource till True och dess CacheDuration egenskap till 30. Låt egenskapen vara inställd på CacheExpirationPolicy standardvärdet . Absolute

Bild 11: Konfigurera ObjectDataSource att cachelagra data i 30 sekunder (Klicka om du vill visa en bild i full storlek)

Spara ändringarna och gå tillbaka till den här sidan i en webbläsare. Texten Selecting event fired visas när du först besöker sidan, eftersom data från början inte finns i cacheminnet. Men efterföljande postbacks som utlöses genom att klicka på Postback-knappen, sortera, bläddra eller klicka på Redigera- eller Avbryt-knapparna visar inte texten för den Välj händelse som utlöses på nytt. Det beror på att Selecting händelsen bara utlöses när ObjectDataSource hämtar sina data från det underliggande objektet. Selecting Händelsen utlöses inte om data hämtas från datacachen.

Efter 30 sekunder tas data bort från cacheminnet. Data tas också bort från cacheminnet om ObjectDataSources Insert, Updateeller Delete -metoderna anropas. När 30 sekunder har gått eller när knappen Uppdatera har klickats, kommer sortering, sidindelning eller att klicka på Redigera eller Avbryt att få ObjectDataSource att hämta sina data från det underliggande objektet, och visar texten från händelsen Selecting när Selecting-händelsen utlöses. Dessa returnerade resultat placeras tillbaka i datacachen.

Bild 12 illustrerar arbetsflödet för Cachelagring av ObjectDataSource. När texten Selecting event fired visas på skärmen beror det på att data inte fanns i cacheminnet och måste hämtas från det underliggande objektet. När den här texten saknas beror det dock på att data var tillgängliga från cacheminnet. När data returneras från cacheminnet finns det inget anrop till det underliggande objektet och därför körs ingen databasfråga.

Bild 12: ObjectDataSource lagrar och hämtar sina data från datacachen

Varje ASP.NET program har en egen datacacheinstans som delas på alla sidor och besökare. Det innebär att data som lagras i datacachen av ObjectDataSource delas på samma sätt mellan alla användare som besöker sidan. Kontrollera detta genom att öppna sidan ObjectDataSource.aspx i en webbläsare. När du först besöker sidan visas texten Selecting event fired (förutsatt att de data som lagts till i cachen av tidigare tester vid det här laget har tagits bort). Öppna en andra webbläsarinstans och kopiera och klistra in URL:en från den första webbläsarinstansen till den andra. I den andra webbläsarinstansen visas inte text som utlöses av markeringshändelsen eftersom den använder samma cachelagrade data som den första.

När hämtad data infogas i cacheminnet använder ObjectDataSource ett cachenyckelvärde som innehåller: egenskapsvärdena CacheDuration och CacheExpirationPolicy, typen av det underliggande affärsobjektet som används av ObjectDataSource, vilket anges via TypeName-egenskapen (ProductsBLL i detta exempel), värdet för SelectMethod-egenskapen samt namn och värden för parametrarna i SelectParameters-samlingen, liksom värdena för dess StartRowIndex och MaximumRows-egenskaper, vilka används vid implementering av anpassad paginering.

Att skapa cachenyckelvärdet som en kombination av dessa egenskaper garanterar en unik cachepost när dessa värden ändras. I tidigare självstudier har vi till exempel tittat på att använda ProductsBLL klassen s GetProductsByCategoryID(categoryID), som returnerar alla produkter för en angiven kategori. En användare kan komma till sidan och se drycker, som har en CategoryID på 1. Om ObjectDataSource cachelagrade sina resultat utan hänsyn till SelectParameters-värdena, när en annan användare kom till sidan för att visa kryddor medan dryckesprodukterna fanns i cachen, skulle de se de cachelagrade dryckesprodukterna istället för kryddor. Genom att variera cachenyckeln efter dessa egenskaper, som innehåller värdena för SelectParameters, behåller ObjectDataSource en separat cachepost för drycker och kryddor.

Problem med inaktuella data

ObjectDataSource avlägsnar automatiskt sina objekt från cacheminnet när någon av dess Insert, Updateeller Delete -metoder anropas. Detta skyddar mot inaktuella data genom att rensa cacheposterna när data ändras via sidan. Det är dock möjligt för en ObjectDataSource som använder cachelagring att fortfarande visa inaktuella data. I det enklaste fallet kan det bero på att data ändras direkt i databasen. Kanske körde en databasadministratör bara ett skript som ändrar några av posterna i databasen.

Det här scenariot kan också utvecklas på ett mer subtilt sätt. Medan ObjectDataSource tar bort sina objekt från cacheminnet när en av dess metoder för dataändring anropas, är de cachelagrade objekten som tas bort för ObjectDataSources specifika kombination av egenskapsvärden (CacheDuration, TypeName, SelectMethodoch så vidare). Om du har två ObjectDataSources som använder olika SelectMethods eller SelectParameters, men fortfarande kan uppdatera samma data, kan en ObjectDataSource uppdatera en rad och ogiltigförklara sina egna cacheposter, men motsvarande rad för den andra ObjectDataSource hanteras fortfarande från cachelagraden. Jag rekommenderar att du skapar sidor för att visa den här funktionen. Skapa en sida som visar en redigerbar GridView som hämtar sina data från en ObjectDataSource som använder cachelagring och är konfigurerad för att hämta data från ProductsBLL klassens GetProducts() -metod. Lägg till en annan redigerbar GridView och ObjectDataSource på den här sidan (eller en annan), men konfigurera den andra ObjectDataSource till att använda GetProductsByCategoryID(categoryID)-metoden. Eftersom de två ObjectDataSources-egenskaperna SelectMethod skiljer sig åt har de var och en sina egna cachelagrade värden. Om du redigerar en produkt i ett rutnät, nästa gång som du kopplar tillbaka data till det andra rutnätet (genom bläddring, sortering och så vidare), kommer det fortfarande att använda gammal cachelagrad data och inte återspegla den ändring som gjordes från det andra rutnätet.

I korthet kan du bara använda tidsbaserade förfallodatum om du är villig att ha potentialen för inaktuella data och använda kortare förfallodatum för scenarier där färskhet av data är viktigt. Om inaktuella data inte är acceptabla avstår du från cachelagring eller använder SQL Cache-beroenden (förutsatt att det är databasdata som du cachelagrar). Vi kommer att utforska SQL-cacheberoenden i en framtida handledning.

Sammanfattning

I den här självstudien undersökte vi objectdatasources inbyggda cachelagringsfunktioner. Genom att bara ange några egenskaper kan vi instruera ObjectDataSource att cachelagra de resultat som returneras från den angivna SelectMethod i ASP.NET datacache. Egenskaperna CacheDuration och CacheExpirationPolicy anger hur länge objektet cachelagras och om det är en absolut eller glidande förfallotid. Egenskapen CacheKeyDependency associerar alla ObjectDataSources cacheposter med ett befintligt cacheberoende. Detta kan användas för att avlägsna ObjectDataSource-posterna från cacheminnet innan den tidsbaserade förfallotiden nås och används vanligtvis med SQL-cacheberoenden.

Eftersom ObjectDataSource helt enkelt cachelagrar sina värden till datacachen kan vi replikera ObjectDataSources inbyggda funktioner programmatiskt. Det är inte meningsfullt att göra detta i presentationsskiktet, eftersom ObjectDataSource erbjuder den här funktionen direkt, men vi kan implementera cachelagringsfunktioner i ett separat lager av arkitekturen. För att göra det måste vi upprepa samma logik som används av ObjectDataSource. Vi ska utforska hur du programmatiskt arbetar med datacachen inifrån arkitekturen i nästa självstudie.

Lycka till med programmerandet!

Ytterligare läsning

Mer information om de ämnen som beskrivs i den här självstudien finns i följande resurser:

• ASP.NET Cachelagring: Tekniker och metodtips
• Arkitekturguide för cachelagring för .NET Framework-program

Om författaren

Scott Mitchell, författare till sju ASP/ASP.NET-böcker och grundare av 4GuysFromRolla.com, har arbetat med Microsofts webbtekniker sedan 1998. Scott arbetar som oberoende konsult, tränare och författare. Hans senaste bok är Sams Teach Yourself ASP.NET 2.0 på 24 timmar. Han kan nås på mitchell@4GuysFromRolla.com.

Särskilt tack till

Den här självstudieserien granskades av många användbara granskare. Ansvarig granskare för den här självstudien var Teresa Murphy. Vill du granska mina kommande MSDN-artiklar? Om så är fallet, hör av dig på mitchell@4GuysFromRolla.com.