Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Autor : Scott Mitchell
Buforowanie może oznaczać różnicę między powolną i szybką aplikacją internetową. Ten samouczek jest pierwszym z czterech, które szczegółowo przyglądają się buforowaniu pamięci podręcznej w ASP.NET. Poznaj kluczowe pojęcia dotyczące buforowania i sposobu stosowania buforowania do warstwy prezentacji za pomocą kontrolki ObjectDataSource.
Wprowadzenie
W nauce komputerowej buforowanie to proces pobierania danych lub informacji, które są kosztowne do uzyskania i przechowywania kopii w lokalizacji, która jest szybciej dostępna. W przypadku aplikacji opartych na danych duże i złożone zapytania często zużywają większość czasu wykonywania aplikacji. Taka wydajność aplikacji może być często lepsza, przechowując wyniki kosztownych zapytań bazy danych w pamięci aplikacji.
ASP.NET 2.0 oferuje różne opcje buforowania. Cała strona internetowa lub renderowana kontrolka użytkownika może być buforowana za pośrednictwem buforowania danych wyjściowych. Kontrolki ObjectDataSource i SqlDataSource zapewniają również funkcje buforowania, co umożliwia buforowanie danych na poziomie kontroli. ASP.NET pamięć podręczna danych udostępnia zaawansowany interfejs API buforowania, który umożliwia deweloperom stron buforowanie obiektów programowo. W tym samouczku i kolejnych trzech omówimy użycie funkcji buforowania obiektu ObjectDataSource, a także pamięci podręcznej danych. Zbadamy również, jak buforować dane dla całej aplikacji podczas uruchamiania i jak utrzymywać aktualność danych w pamięci podręcznej za pomocą zależności SQL. Te samouczki nie eksplorują buforowania danych wyjściowych. Aby uzyskać szczegółowe informacje na temat buforowania danych wyjściowych, zobacz Buforowanie danych wyjściowych w ASP.NET 2.0.
Buforowanie można stosować w dowolnym miejscu w architekturze z warstwy dostępu do danych w górę przez warstwę prezentacji. W tym samouczku przyjrzymy się zastosowaniu buforowania do warstwy prezentacji za pomocą kontrolki ObjectDataSource. W następnym samouczku przeanalizujemy buforowanie danych w warstwie logiki biznesowej.
Kluczowe pojęcia dotyczące buforowania
Buforowanie może znacznie poprawić ogólną wydajność i skalowalność aplikacji, umożliwiając wykorzystanie danych, które są kosztowne do wygenerowania, i przechowywanie ich kopii w lokalizacji, z której można bardziej efektywnie uzyskiwać dostęp. Ponieważ pamięć podręczna przechowuje tylko kopię rzeczywistych, bazowych danych, może stać się nieaktualna lub nieaktualna, jeśli bazowe dane się zmienią. Aby temu zaradzić, deweloper strony może wskazać kryteria usunięcia elementu z pamięci podręcznej przy użyciu:
- Kryteria oparte na czasie pozwalają na dodanie elementu do pamięci podręcznej na bezwzględny lub przesuwany czas trwania. Na przykład deweloper strony może wskazywać czas trwania, na przykład 60 sekund. W przypadku bezwzględnego czasu trwania buforowany element jest eksmitowany 60 sekund po dodaniu go do pamięci podręcznej, niezależnie od tego, jak często był uzyskiwany dostęp. Dzięki przesuwanemu czasowi wygaśnięcia buforowany element jest usuwany 60 sekund po ostatnim dostępie.
- Kryteria oparte na zależnościach zależność można skojarzyć z elementem po dodaniu do pamięci podręcznej. Gdy zależność elementu zmienia się, jest eksmitowana z pamięci podręcznej. Zależność może być plikiem, innym elementem pamięci podręcznej lub kombinacją tych dwóch elementów. ASP.NET 2.0 umożliwia również zależności pamięci podręcznej SQL, które umożliwiają deweloperom dodawanie elementu do pamięci podręcznej i eksmitowanie ich po zmianie bazowych danych. W ramach nadchodzącego samouczka Korzystanie z zależności pamięci podręcznej SQL Cache sprawdzimy zależności pamięci podręcznej SQL.
Niezależnie od określonych kryteriów eksmisji element w pamięci podręcznej może zostać usunięty przed spełnieniem kryteriów opartych na czasie lub zależności. Jeśli pamięć podręczna osiągnęła pojemność, należy usunąć istniejące elementy przed dodaniu nowych. W związku z tym podczas programowej pracy z zapisanymi w pamięci podręcznej danymi ważne jest, aby zawsze zakładać, że buforowane dane mogą nie być obecne. Przyjrzymy się schematowi stosowanemu podczas programowego dostępu do danych z pamięci podręcznej w następnym samouczku, Buforowanie danych w architekturze.
Buforowanie zapewnia ekonomiczne środki do zwiększenia wydajności aplikacji. Jak mówi Steven Smith w swoim artykule ASP.NET buforowanie: techniki i najlepsze rozwiązania:
Buforowanie może być dobrym sposobem na osiągnięcie wystarczającej wydajności bez potrzeby poświęcania dużo czasu na analizę. Pamięć jest tania, więc jeśli możesz uzyskać potrzebną wydajność, buforując dane wyjściowe przez 30 sekund, zamiast spędzać dzień lub tydzień próbując zoptymalizować kod lub bazę danych, zastosuj rozwiązanie buforowania (zakładając, że 30-sekundowe dane są w porządku) i kontynuuj. W końcu słabe projektowanie prawdopodobnie spowoduje problemy, więc oczywiście należy poprawnie zaprojektować aplikacje. Ale jeśli po prostu potrzebujesz uzyskać wystarczającą wydajność dzisiaj, pamięć podręczna może być doskonałym podejściem, dając ci czas na zrefaktoryzowanie aplikacji w późniejszym terminie, gdy będziesz mieć na to czas.
Buforowanie może zapewnić istotne ulepszenia wydajności, ale nie ma zastosowania we wszystkich sytuacjach, takich jak w przypadku aplikacji korzystających z danych w czasie rzeczywistym, często aktualizowanych danych lub gdy nawet krótkotrwałe nieaktualne dane są niedopuszczalne. Jednak w przypadku większości aplikacji buforowanie powinno być używane. Aby uzyskać więcej informacji na temat buforowania w programie ASP.NET 2.0, zapoznaj się z sekcją Buforowanie wydajności w samouczkach Szybki start ASP.NET 2.0.
Krok 1: Tworzenie stron internetowych z buforowaniem
Zanim zaczniemy eksplorować funkcje buforowania ObjectDataSource, najpierw poświęćmy chwilę, aby utworzyć strony ASP.NET w projekcie naszej witryny, które będą potrzebne w tym samouczku i trzech kolejnych. Zacznij od dodania nowego folderu o nazwie Caching. Następnie dodaj następujące strony ASP.NET do tego folderu, aby skojarzyć każdą stronę ze stroną wzorcową Site.master :
Default.aspxObjectDataSource.aspxFromTheArchitecture.aspxAtApplicationStartup.aspxSqlCacheDependencies.aspx
Rysunek 1. Dodaj strony ASP.NET dla samouczków Caching-Related
Podobnie jak w innych folderach, Default.aspx w folderze Caching wyświetli listę samouczków w swojej sekcji. Pamiętaj, że kontrolka SectionLevelTutorialListing.ascx użytkownika udostępnia tę funkcję. W związku z tym dodaj tę kontrolkę użytkownika Default.aspx przeciągając ją z Eksploratora rozwiązań na stronę w widoku Projektu.
Rysunek 2. Rysunek 2. Dodawanie kontrolki SectionLevelTutorialListing.ascx użytkownika do Default.aspx (kliknij, aby wyświetlić obraz pełnowymiarowy)
Na koniec dodaj te strony jako wpisy do Web.sitemap pliku. W szczególności dodaj następujący znacznik po "praca z danymi binarnymi" <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>
Po zaktualizowaniu Web.sitemap programu, poświęć chwilę, aby wyświetlić witrynę internetową samouczków za pośrednictwem przeglądarki. Menu po lewej stronie zawiera teraz elementy dotyczące samouczków buforowania.
Rysunek 3. Mapa witryny zawiera teraz wpisy dla samouczków buforowania
Krok 2. Wyświetlanie listy produktów na stronie sieci Web
W tym samouczku przedstawiono sposób używania wbudowanych funkcji buforowania kontrolki ObjectDataSource. Zanim jednak przyjrzymy się tym funkcjom, najpierw potrzebujemy strony do pracy. Utwórzmy stronę internetową, która używa kontrolki GridView do wyświetlania listy informacji o produkcie pobranych przez obiekt ObjectDataSource z ProductsBLL klasy .
Rozpocznij od otwarcia strony ObjectDataSource.aspx w folderze Caching. Przeciągnij kontrolkę GridView z przybornika do projektanta, ustaw jej ID właściwość na Products, a następnie z tagu inteligentnego wybierz powiązanie go z nową kontrolką ObjectDataSource o nazwie ProductsDataSource. Skonfiguruj obiekt ObjectDataSource do pracy z klasą ProductsBLL .
Rysunek 4. Konfigurowanie obiektu ObjectDataSource do używania ProductsBLL klasy (kliknij, aby wyświetlić obraz o pełnym rozmiarze)
Na tej stronie utwórzmy edytowalny element GridView, abyśmy mogli sprawdzić, co się stanie, gdy dane buforowane w obiekcie ObjectDataSource zostaną zmodyfikowane za pośrednictwem interfejsu kontrolki GridView. Pozostaw listę rozwijaną na karcie SELECT ustawioną na wartość domyślną, GetProducts(), ale zmień wybrany element na karcie UPDATE na przeciążoną wersję UpdateProduct, która akceptuje productName, unitPrice i productID jako parametry wejściowe.
Rysunek 5: Ustaw listę Drop-Down zakładki AKTUALIZACJi na odpowiednie UpdateProduct przeciążenie (kliknij, aby wyświetlić obraz pełnowymiarowy)
Na koniec ustaw listy rozwijane na kartach INSERT i DELETE na wartość (Brak), a następnie kliknij przycisk Zakończ. Po ukończeniu pracy Kreatora konfigurowania źródła danych program Visual Studio ustawia właściwość ObjectDataSource OldValuesParameterFormatString na original_{0} wartość. Zgodnie z opisem w samouczku Omówienie wstawiania, aktualizowania i usuwania danych ta właściwość musi zostać usunięta ze składni deklaratywnej lub ustawiona z powrotem na jej wartość domyślną, {0}aby przepływ pracy aktualizacji był kontynuowany bez błędu.
Ponadto po zakończeniu pracy kreatora program Visual Studio dodaje pole do kontrolki GridView dla każdego pola danych produktu. Usuń wszystkie elementy, z wyjątkiem pól ProductName, CategoryName, i UnitPrice BoundFields. Następnie zaktualizuj HeaderText właściwości każdego z tych pól powiązanych odpowiednio do Produktu, Kategorii i Ceny.
ProductName Ponieważ pole jest wymagane, przekonwertuj BoundField na TemplateField i dodaj RequiredFieldValidator do obiektu EditItemTemplate. Podobnie przekonwertuj UnitPrice pole BoundField na wartość TemplateField i dodaj moduł CompareValidator, aby upewnić się, że wartość wprowadzona przez użytkownika jest prawidłową wartością waluty większą lub równą zero. Oprócz tych modyfikacji możesz swobodnie wprowadzać wszelkie zmiany estetyczne, takie jak wyrównanie wartości UnitPrice do prawej lub określenie formatowania tekstu UnitPrice w interfejsach do odczytu i edycji.
Ustaw element GridView jako edytowalny, zaznaczając pole wyboru Włącz edycję w tagu inteligentnym GridView. Zaznacz również pola wyboru Włącz stronicowanie i Włącz sortowanie.
Uwaga / Notatka
Potrzebujesz przeglądu sposobu dostosowywania interfejsu edycji GridView? Jeśli tak, zapoznaj się z samouczkiem Dostosowywanie interfejsu modyfikacji danych .
Rysunek 6. Włączanie obsługi kontrolki GridView na potrzeby edycji, sortowania i stronicowania (kliknij, aby wyświetlić obraz pełnowymiarowy)
Po wprowadzeniu tych modyfikacji, znacznik deklaratywny GridView i ObjectDataSource powinien wyglądać podobnie do następującego:
<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>
Jak pokazano na rysunku 7, edytowalny element GridView wyświetla nazwę, kategorię i cenę każdego z produktów w bazie danych. Pośmiń chwilę na przetestowanie funkcjonalności strony posortowania wyników, stronicowania ich i edytowania rekordu.
Rysunek 7. Każda nazwa produktu, kategoria i cena są wyświetlane w widoku Sortable, Pageable, Editable GridView (Kliknij, aby wyświetlić obraz pełnowymiarowy)
Krok 3. Badanie, kiedy obiekt ObjectDataSource żąda danych
Products GridView pobiera swoje dane do wyświetlenia, wywołując metodę Select obiektu ProductsDataSource ObjectDataSource. Ten element ObjectDataSource tworzy wystąpienie klasy ProductsBLL warstwy logiki biznesowej i wywołuje jej metodę GetProducts(), która z kolei wywołuje metodę ProductsTableAdapterGetProducts() warstwy dostępu do danych. Metoda DAL łączy się z bazą danych Northwind i wystawia skonfigurowane SELECT zapytanie. Te dane są następnie zwracane do DAL, który je pakuje w NorthwindDataTable. Obiekt DataTable jest zwracany do biblioteki BLL, która zwraca go do obiektu ObjectDataSource, który zwraca go do kontrolki GridView. Następnie GridView tworzy obiekt GridViewRow dla każdego DataRow w tabeli DataTable, a każdy GridViewRow jest ostatecznie renderowany w kodzie HTML zwracanym do klienta i wyświetlanym w przeglądarce odwiedzającego.
Ta sekwencja zdarzeń odbywa się za każdym razem, gdy GridView musi powiązać swoje dane źródłowe. Dzieje się tak, gdy strona jest najpierw odwiedzana, podczas przechodzenia z jednej strony danych do innej, podczas sortowania kontrolki GridView lub podczas modyfikowania danych kontrolki GridView za pomocą wbudowanej edycji lub usuwania interfejsów. Jeśli stan widoku kontrolki GridView jest wyłączony, element GridView będzie wiązany ponownie na każdej zwrotnej przesyłce. Obiekt GridView może również zostać jawnie powiązany z danymi przez wywołanie metody DataBind().
Aby w pełni docenić częstotliwość pobierania danych z bazy danych, wyświetlmy komunikat wskazujący, kiedy dane są pobierane ponownie. Dodaj kontrolkę etykiety sieci web o nazwie ODSEvents nad kontrolką GridView. Wyczyść jej Text właściwość i ustaw jej EnableViewState właściwość na false. Poniżej etykiety dodaj kontrolkę przycisku Web i ustaw jej właściwość na Postback.
Rysunek 8. Dodawanie etykiety i przycisku do strony powyżej kontrolki GridView (kliknij, aby wyświetlić obraz pełnowymiarowy)
Podczas przepływu pracy dostępu do danych zdarzenie ObjectDataSource Selecting jest uruchamiane przed utworzeniem obiektu bazowego i zanim jej skonfigurowana metoda jest wywoływana. Utwórz procedurę obsługi zdarzeń dla tego zdarzenia i dodaj następujący kod:
protected void ProductsDataSource_Selecting(object sender,
ObjectDataSourceSelectingEventArgs e)
{
ODSEvents.Text = "-- Selecting event fired";
}
Za każdym razem, gdy obiekt ObjectDataSource wysyła żądanie do architektury danych, etykieta wyświetli tekst Wydarzenie wybierania uruchomione.
Odwiedź tę stronę w przeglądarce. Po pierwszym odwiedzeniu strony wyświetlany jest tekst informujący o aktywacji zdarzenia. Kliknij przycisk Postback i zwróć uwagę, że tekst zniknie (przy założeniu, że właściwość GridView jest EnableViewState ustawiona na true, wartość domyślna). Wynika to z faktu, że przy zwrotnym przesłaniu element GridView jest odbudowywany z jego stanu widoku i dlatego nie pobiera danych z ObjectDataSource. Sortowanie, stronicowanie lub edytowanie danych powoduje jednak ponowne powiązanie kontrolki GridView ze źródłem danych, a zatem tekst wyświetlany po wywołaniu zdarzenia Selecting pojawia się ponownie.
Rysunek 9. Zawsze, gdy kontrolka GridView jest przywracana do źródła danych, wyświetlane jest wyzwalane zdarzenie Selecting event (Kliknij, aby wyświetlić obraz o pełnym rozmiarze)
Rysunek 10: Kliknięcie przycisku Postback powoduje odtworzenie GridView na podstawie stanu widoku (kliknij, aby wyświetlić obraz w pełnym rozmiarze)
Może się wydawać marnotrawne pobieranie danych bazy danych za każdym razem, gdy dane są stronicowane lub posortowane. W końcu, ponieważ używamy domyślnego stronicowania, źródło ObjectDataSource pobrało wszystkie rekordy podczas wyświetlania pierwszej strony. Nawet jeśli kontrolka GridView nie zapewnia obsługi sortowania i stronicowania, dane muszą być pobierane z bazy danych za każdym razem, gdy strona jest najpierw odwiedzana przez dowolnego użytkownika (i na każdym podaniu zwrotnym, jeśli stan widoku jest wyłączony). Jeśli jednak kontrolka GridView wyświetla te same dane wszystkim użytkownikom, te dodatkowe żądania bazy danych są zbędne. Dlaczego nie buforować wyników zwróconych z GetProducts() metody i powiązać element GridView z tymi buforowanymi wynikami?
Krok 4. Buforowanie danych przy użyciu obiektu ObjectDataSource
Po prostu ustawiając kilka właściwości, można skonfigurować obiekt ObjectDataSource tak, aby automatycznie buforował pobrane dane w pamięci podręcznej danych ASP.NET. Poniższa lista zawiera podsumowanie właściwości związanych z pamięcią podręczną obiektu ObjectDataSource:
- Aby włączyć buforowanie, należy ustawić EnableCaching na
true. Wartość domyślna tofalse. -
Czas przechowywania w buforze określa ilość czasu, w sekundach, przez który dane są przechowywane. Wartość domyślna to 0. Obiekt ObjectDataSource będzie buforować dane tylko wtedy, gdy
EnableCachingjesttrueiCacheDurationjest ustawiona na wartość większą niż zero. -
CacheExpirationPolicy można ustawić na
AbsolutelubSliding. JeśliAbsolute, obiekt ObjectDataSource buforuje pobrane dane przezCacheDurationsekund; jeśliSliding, dane wygasają dopiero po tym, jak nie były dostępne przezCacheDurationsekund. Wartość domyślna toAbsolute. -
CacheKeyDependency używa tej właściwości, aby skojarzyć wpisy pamięci podręcznej ObjectDataSource z istniejącą zależnością pamięci podręcznej. Wpisy danych obiektu ObjectDataSource mogą zostać przedwcześnie wykluczone z pamięci podręcznej przez wygaśnięcie skojarzonego z nim elementu
CacheKeyDependency. Ta właściwość jest najczęściej używana do kojarzenia zależności pamięci podręcznej SQL z pamięcią podręczną ObjectDataSource— temat, który omówimy w przyszłym tutorialu Używanie zależności pamięci podręcznej SQL.
Skonfigurujmy obiekt ProductsDataSource ObjectDataSource w celu buforowania danych przez 30 sekund w skali bezwzględnej. Ustaw właściwość EnableCaching dla ObjectDataSource na true oraz jego właściwość CacheDuration na 30. Pozostaw właściwość ustawioną CacheExpirationPolicy na wartość domyślną Absolute.
Rysunek 11. Konfigurowanie obiektu ObjectDataSource w celu buforowania danych przez 30 sekund (kliknij, aby wyświetlić obraz o pełnym rozmiarze)
Zapisz zmiany i ponownie sprawdź tę stronę w przeglądarce. Przy pierwszym wejściu na stronę pojawi się tekst informujący o uruchomieniu zdarzenia wybierania, ponieważ początkowo dane nie znajdują się w pamięci podręcznej. Jednak kolejne zwrotne wywołania wyzwolone przez kliknięcie przycisku Postback, sortowanie, stronicowanie lub kliknięcie przycisków Edytuj lub Anuluj nie powoduje ponownego wyświetlenia tekstu wyzwolonego przez zdarzenie Selecting. Dzieje się tak, ponieważ Selecting zdarzenie jest uruchamiane tylko wtedy, gdy obiekt ObjectDataSource pobiera dane z jego obiektu bazowego. Selecting Zdarzenie nie jest uruchamiane, jeśli dane są pobierane z pamięci podręcznej danych.
Po 30 sekundach dane zostaną wykluczone z pamięci podręcznej. Dane będą również eksmitowane z pamięci podręcznej, jeśli wywoływane są metody ObjectDataSource s Insert, Updatelub Delete . W związku z tym, po upływie 30 sekund lub kliknięciu przycisku Aktualizuj, sortowanie, stronicowanie lub kliknięcie przycisków Edytuj lub Anuluj spowoduje, że ObjectDataSource pobierze dane ze swojego obiektu bazowego, wyświetlając tekst dotyczący wyzwolenia zdarzenia Selecting, gdy zdarzenie Selecting zostanie wywołane. Te zwrócone wyniki są umieszczane z powrotem w pamięci podręcznej danych.
Uwaga / Notatka
Jeśli zobaczysz, że zdarzenie Selecting jest uruchamiane często, nawet jeśli oczekujesz, że obiekt ObjectDataSource będzie działać z danymi w pamięci podręcznej, może to być spowodowane ograniczeniami pamięci. Jeśli jest za mało wolnej pamięci, dane dodane do pamięci podręcznej przez element ObjectDataSource mogły zostać usunięte. Jeśli obiekt ObjectDataSource nie będzie poprawnie buforować danych lub buforuje dane sporadycznie, zamknij niektóre aplikacje, aby zwolnić pamięć i spróbuj ponownie.
Rysunek 12 ilustruje przepływ pracy buforowania obiektu ObjectDataSource. Gdy na ekranie pojawi się tekst Selecting event (Zdarzenie wybierania), oznacza to, że dane nie znajdowały się w pamięci podręcznej i musiały zostać pobrane z obiektu bazowego. Jeśli jednak brakuje tego tekstu, jest to spowodowane tym, że dane były dostępne z pamięci podręcznej. Gdy dane są zwracane z pamięci podręcznej, nie ma wywołania obiektu bazowego i dlatego żadne zapytanie bazy danych nie jest wykonywane.
Rysunek 12: ObjectDataSource przechowuje i pobiera dane z pamięci podręcznej danych
Każda aplikacja ASP.NET ma własne wystąpienie pamięci podręcznej danych, które jest współużytkowane przez wszystkie strony i odwiedzających. Oznacza to, że dane przechowywane w pamięci podręcznej danych przez obiekt ObjectDataSource są podobnie współużytkowane przez wszystkich użytkowników odwiedzających stronę. Aby to sprawdzić, otwórz ObjectDataSource.aspx stronę w przeglądarce. Przy pierwszej wizycie na stronie pojawi się tekst 'Wybieranie zdarzenia' (zakładając, że dane dodane do pamięci podręcznej przez poprzednie testy zostały usunięte). Otwórz drugie wystąpienie przeglądarki i skopiuj i wklej adres URL z pierwszego wystąpienia przeglądarki do drugiego. W drugim wystąpieniu przeglądarki nie jest wyświetlany tekst wyzwolony podczas wybierania zdarzenia, ponieważ używa on tych samych danych w pamięci podręcznej co pierwszy.
Podczas wstawiania pobranych danych do pamięci podręcznej, ObjectDataSource używa wartości klucza pamięci podręcznej, która zawiera: wartości właściwości
Utworzenie wartości klucza pamięci podręcznej jako kombinacji tych właściwości zapewnia unikatowy wpis pamięci podręcznej w miarę zmiany tych wartości. Na przykład w poprzednich samouczkach omówiliśmy użycie ProductsBLL klasy s GetProductsByCategoryID(categoryID), która zwraca wszystkie produkty dla określonej kategorii. Jeden użytkownik może przyjść na stronę i wyświetlić napoje, które mają CategoryID wartość 1. Jeśli obiekt ObjectDataSource przechowywał wyniki bez względu na SelectParameters wartości, to gdyby inny użytkownik przyszedł na stronę, aby wyświetlić przyprawy, podczas gdy w pamięci podręcznej znajdowały się produkty napojów, zobaczyłby buforowane produkty napojów, a nie przyprawy. Zmieniając klucz pamięci podręcznej według tych właściwości, które obejmują wartości SelectParameters, obiekt ObjectDataSource utrzymuje oddzielny wpis pamięci podręcznej dla napojów i przypraw.
Nieaktualne obawy dotyczące danych
Obiekt ObjectDataSource automatycznie eksmituje swoje elementy z pamięci podręcznej po wywołaniu dowolnej z metod Insert, Updatelub Delete . Pomaga to chronić przed nieaktualnymi danymi przez wyczyszczenie wpisów pamięci podręcznej, gdy dane są modyfikowane za pośrednictwem strony. Jednak istnieje możliwość, aby obiekt ObjectDataSource używał buforowania, aby nadal wyświetlać nieaktualne dane. W najprostszym przypadku może to być spowodowane zmianą danych bezpośrednio w bazie danych. Być może administrator bazy danych właśnie uruchomił skrypt, który modyfikuje niektóre rekordy w bazie danych.
Ten scenariusz może również rozwinąć się w bardziej subtelny sposób. Podczas gdy ObjectDataSource usuwa elementy z pamięci podręcznej, gdy wywoływana jest jedna z metod modyfikacji danych, usunięte elementy buforowane dotyczą konkretnej kombinacji wartości właściwości ObjectDataSource (CacheDuration, TypeName, SelectMethod itd.). Jeśli masz dwa źródła danych ObjectDataSources, które używają różnych SelectMethods lub SelectParameters, ale nadal mogą aktualizować te same dane, jedno źródło danych może zaktualizować wiersz i unieważnić własne wpisy pamięci podręcznej, jednak dla drugiego źródła ten sam wiersz nadal będzie obsługiwany z pamięci podręcznej. Zachęcam do tworzenia stron, aby pokazać tę funkcjonalność. Utwórz stronę wyświetlającą edytowalny GridView, który pobiera dane z ObjectDataSource korzystającego z buforowania i jest skonfigurowany do pobierania danych z metody ProductsBLL klasy GetProducts(). Dodaj kolejną edytowalną kontrolkę GridView i ObjectDataSource do tej strony (lub innej), ale dla tej drugiej kontrolki ObjectDataSource użyj metody GetProductsByCategoryID(categoryID). Ponieważ dwie właściwości ObjectDataSources SelectMethod różnią się, każda z nich ma własne wartości buforowane. Jeśli edytujesz produkt w jednej siatce, przy następnym powiązaniu danych ponownie z drugą siatką (poprzez stronicowanie, sortowanie i tak dalej), nadal będą wyświetlane stare, buforowane dane i nie odzwierciedlą zmiany wprowadzonej w drugiej siatce.
Krótko mówiąc, używaj tylko terminów wygaśnięcia opartych na czasie, jeśli chcesz mieć potencjał nieaktualnych danych i używaj krótszych wygasań w scenariuszach, w których świeżość danych jest ważna. Jeśli nieaktualne dane nie są akceptowalne, należy zrezygnować z buforowania lub użyć zależności pamięci podręcznej SQL (zakładając, że są to dane bazy danych, które są buforowane). W przyszłym samouczku zapoznamy się z zależnościami pamięci podręcznej SQL.
Podsumowanie
W tym samouczku przeanalizowaliśmy wbudowane możliwości buforowania obiektu ObjectDataSource. Po prostu ustawiając kilka właściwości, możemy poinstruować ObjectDataSource, aby zapisywać wyniki zwrócone z określonej SelectMethod do pamięci podręcznej danych ASP.NET. Właściwości CacheDuration i CacheExpirationPolicy wskazują czas trwania buforowania elementu i określa, czy jest to wygaśnięcie bezwzględne, czy przesuwane. Właściwość CacheKeyDependency kojarzy wszystkie wpisy pamięci podręcznej ObjectDataSource z istniejącą zależnością pamięci podręcznej. Można to wykorzystać do usunięcia wpisów ObjectDataSource z pamięci podręcznej przed osiągnięciem planowanego czasu wygaśnięcia i zwykle używa się tego z zależnościami SQL dla pamięci podręcznej.
Ponieważ obiekt ObjectDataSource po prostu buforuje swoje wartości w pamięci podręcznej danych, możemy programowo replikować wbudowane funkcje obiektu ObjectDataSource. Nie ma sensu, aby to zrobić w warstwie prezentacji, ponieważ obiekt ObjectDataSource oferuje tę funkcję poza ramką, ale możemy zaimplementować funkcje buforowania w oddzielnej warstwie architektury. W tym celu musimy powtórzyć tę samą logikę używaną przez obiekt ObjectDataSource. W następnym samouczku dowiemy się, jak programowo pracować z pamięcią podręczną danych w ramach architektury.
Szczęśliwe programowanie!
Dalsza lektura
Aby uzyskać więcej informacji na temat tematów omówionych w tym samouczku, zapoznaj się z następującymi zasobami:
- ASP.NET buforowanie: techniki i najlepsze rozwiązania
- Przewodnik po architekturze buforowania dla aplikacji .NET Framework
Informacje o autorze
Scott Mitchell, autor siedmiu książek ASP/ASP.NET i założyciel 4GuysFromRolla.com, współpracuje z technologiami internetowymi firmy Microsoft od 1998 roku. Scott pracuje jako niezależny konsultant, trener i pisarz. Jego najnowsza książka to Sams Teach Yourself ASP.NET 2.0 w ciągu 24 godzin. Można go uzyskać pod adresem mitchell@4GuysFromRolla.com.
Specjalne podziękowania
Ta seria samouczków została omówiona przez wielu przydatnych recenzentów. Główny recenzent tego samouczka to Teresa Murphy. Chcesz przejrzeć nadchodzące artykuły MSDN? Jeśli tak, napisz do mnie na adres mitchell@4GuysFromRolla.com.