Buforowanie danych przy uruchamianiu aplikacji (VB)

Autor : Scott Mitchell

Pobierz plik PDF

W dowolnej aplikacji internetowej niektóre dane będą często używane, a niektóre dane będą rzadko używane. Możemy poprawić wydajność naszej aplikacji ASP.NET, ładując z wyprzedzeniem często używane dane, technika znana jako. W tym samouczku przedstawiono jedno podejście do ładowania danych z wyprzedzeniem, które polega na ładowaniu danych do cache podczas uruchamiania aplikacji.

Wprowadzenie

W dwóch poprzednich samouczkach przedstawiono buforowanie danych w warstwach prezentacji i buforowania. W temacie Buforowanie danych za pomocą elementu ObjectDataSource przyjrzeliśmy się użyciu funkcji buforowania elementu ObjectDataSource do buforowania danych w warstwie prezentacji. Buforowanie danych w architekturze przeanalizował buforowanie w nowej, oddzielnej warstwie buforowania. Oba te samouczki korzystały z reaktywnego ładowania podczas pracy z pamięcią podręczną danych. W przypadku ładowania reaktywnego, za każdym razem, gdy żądane są dane, system najpierw sprawdza, czy znajdują się one w pamięci podręcznej. Jeśli tak nie jest, pobiera dane ze źródła źródłowego, takiego jak baza danych, a następnie przechowuje je w pamięci podręcznej. Główną zaletą reaktywnego ładowania jest łatwość implementacji. Jedną z jego wad jest nierówna wydajność przy obsłudze żądań. Wyobraź sobie stronę, która używa warstwy buforowania z poprzedniego samouczka do wyświetlania informacji o produkcie. Gdy ta strona jest odwiedzana po raz pierwszy lub po usunięciu z pamięci podręcznej z powodu ograniczeń pamięci albo po osiągnięciu określonego czasu wygaśnięcia, dane muszą zostać pobrane z bazy danych. W związku z tym żądania tych użytkowników będą trwać dłużej niż żądania użytkowników, które mogą być obsługiwane przez pamięć podręczną.

Proaktywne ładowanie zapewnia alternatywną strategię zarządzania pamięcią podręczną, która wygładza wydajność między żądaniami, ładując dane z pamięci podręcznej, zanim będą potrzebne. Zazwyczaj aktywne ładowanie korzysta z pewnego procesu, który okresowo sprawdza lub jest powiadamiany o aktualizacji danych bazowych. Następnie ten proces aktualizuje pamięć podręczną, aby zachować jej świeżość. Aktywne ładowanie jest szczególnie przydatne, jeśli bazowe dane pochodzą z powolnego połączenia z bazą danych, usługi sieci Web lub innego szczególnie powolnego źródła danych. Jednak takie podejście do proaktywnego ładowania jest trudniejsze do zaimplementowania, ponieważ wymaga tworzenia i wdrażania procesu w celu sprawdzania zmian i aktualizowania pamięci podręcznej.

Inną odmianą proaktywnego ładowania, którą będziemy omawiać w tym samouczku, jest ładowanie danych do pamięci podręcznej podczas uruchamiania aplikacji. Takie podejście jest szczególnie przydatne w przypadku buforowania danych statycznych, takich jak rekordy w tabelach odnośników bazy danych.

Uwaga / Notatka

Aby uzyskać bardziej szczegółowe informacje na temat różnic między aktywnym i reaktywnym ładowaniem, a także listami zalet, wad i zaleceń dotyczących implementacji, zapoznaj się z sekcją Zarządzanie zawartością pamięci podręcznejprzewodnika po architekturze buforowania dla aplikacji .NET Framework.

Krok 1. Określanie danych do buforowania podczas uruchamiania aplikacji

Przykłady buforowania przy wykorzystaniu reaktywnego ładowania, które omówiliśmy w dwóch poprzednich samouczkach, dobrze działają z danymi, które mogą okresowo się zmieniać i do wygenerowania nie wymagają nadmiernie dużo czasu. Jeśli jednak buforowane dane nigdy się nie zmieniają, przedawnienie stosowane przez ładowanie reaktywne jest zbędne. Podobnie, jeśli generowanie buforowanych danych zajmuje niezwykle dużo czasu, użytkownicy, których żądania trafią na pustą pamięć podręczną, będą musieli czekać przez długi czas, aż podstawowe dane zostaną pobrane. Rozważ buforowanie danych statycznych i danych, których wygenerowanie zajmuje wyjątkowo dużo czasu podczas uruchamiania aplikacji.

Chociaż bazy danych mają wiele dynamicznych, często zmieniających się wartości, większość ma również dość dużo danych statycznych. Na przykład praktycznie wszystkie modele danych mają co najmniej jedną kolumnę zawierającą określoną wartość z stałego zestawu wyborów. Patients Tabela bazy danych może zawierać kolumnęPrimaryLanguage, której zestaw wartości może być angielski, hiszpański, francuski, rosyjski, japoński itd. Często te typy kolumn są implementowane przy użyciu tabel odnośników. Zamiast przechowywać ciąg angielski lub francuski w Patients tabeli, tworzona jest druga tabela, która zawiera często dwie kolumny — unikatowy identyfikator i opis ciągu — z rekordem dla każdej możliwej wartości. Kolumna PrimaryLanguage w tabeli Patients przechowuje odpowiadający unikatowy identyfikator w tabeli pomocniczej. Na rycinie 1 głównym językiem pacjenta Johna Doe jest angielski, podczas gdy Eda Johnsona jest rosyjski.

Rysunek 1.Languages Tabela jest tabelą odnośników używaną przez tabelę Patients

Interfejs użytkownika do edycji lub tworzenia nowego pacjenta zawiera listę rozwijaną dozwolonych języków wypełnionych rekordami w Languages tabeli. Bez buforowania za każdym razem, gdy ten interfejs jest odwiedzany, system musi wykonywać zapytania względem Languages tabeli. To marnotrawstwo i niepotrzebne, ponieważ wartości tabeli odnośników zmieniają się bardzo rzadko, jeśli w ogóle.

Możemy buforować dane Languages przy użyciu tych samych technik ładowania reaktywnego, które były omawiane w poprzednich samouczkach. Czasowe wygaśnięcie, stosowane w ładowaniu reaktywnym, nie jest jednak potrzebne dla danych statycznej tabeli wyszukiwania. Buforowanie przy użyciu ładowania reaktywnego byłoby lepsze niż w przypadku braku buforowania, ale najlepszym rozwiązaniem byłoby proaktywne ładowanie danych tabeli odnośników do pamięci podręcznej podczas uruchamiania aplikacji.

W tym samouczku dowiesz się, jak buforować dane tabeli odnośników i inne informacje statyczne.

Krok 2. Badanie różnych sposobów buforowania danych

Informacje mogą być programowo buforowane w aplikacji ASP.NET przy użyciu różnych metod. Widzieliśmy już, jak używać pamięci podręcznej danych w poprzednich samouczkach. Alternatywnie obiekty mogą być programowo buforowane przy użyciu statycznych elementów członkowskich lub stanu aplikacji.

Podczas pracy z klasą zazwyczaj należy utworzyć wystąpienie klasy przed uzyskaniem dostępu do jej członów. Aby na przykład wywołać metodę z jednej z klas w warstwie logiki biznesowej, musimy najpierw utworzyć wystąpienie klasy:

Dim productsAPI As New ProductsBLL()
productsAPI.SomeMethod()
productsAPI.SomeProperty = "Hello, World!"

Aby można było wywołać metodę SomeMethod lub pracować z elementem SomeProperty, musimy najpierw utworzyć wystąpienie klasy przy użyciu słowa kluczowego New . SomeMethod i SomeProperty są powiązane z konkretnym wystąpieniem. Czas życia tych członków jest powiązany z czasem życia skojarzonego obiektu. Statyczne elementy członkowskie, z drugiej strony, to zmienne, właściwości i metody, które są współużytkowane przez wszystkie wystąpienia klasy, a w związku z tym mają okres istnienia tak długo, jak klasa. Statyczne elementy członkowskie są oznaczane przez słowo kluczowe Shared.

Oprócz statycznych członków dane mogą być buforowane za pomocą stanu aplikacji. Każda aplikacja ASP.NET utrzymuje kolekcję nazw/wartości, która jest współużytkowana przez wszystkich użytkowników i strony aplikacji. Dostęp do tej kolekcji można uzyskać za pomocą HttpContext właściwości sApplicationklasy i używać z klasy związanej z kodem ASP.NET page s, w następujący sposób:

Application("key") = value
Dim value As Object = Application("key")

Pamięć podręczna danych umożliwia dostęp do znacznie bogatszego interfejsu API do przechowywania danych, oferując mechanizmy wygasania na podstawie czasu i zależności, priorytety elementów pamięci podręcznej itd. W przypadku statycznych elementów członkowskich i stanu aplikacji takie funkcje muszą zostać ręcznie dodane przez dewelopera strony. Jednak w przypadku buforowania danych podczas uruchamiania aplikacji przez cały okres istnienia aplikacji zalety pamięci podręcznej danych są dyskusyjne. W tym samouczku przyjrzymy się kodowi, który wykorzystuje wszystkie trzy techniki buforowania danych statycznych.

Krok 3. BuforowanieSuppliersdanych tabeli

Tabele bazy danych Northwind, które zaimplementowaliśmy do teraz, nie zawierają żadnych tradycyjnych tabel wyszukiwania. Cztery tabele DataTable zaimplementowane w naszej warstwie dostępu do danych (DAL) modelują tabele, których wartości są zmienne. Zamiast poświęcać czas na dodawanie nowego DataTable do DAL, a następnie nowej klasy i metod do BLL, w tym samouczku po prostu udawajmy, że Suppliers dane tabeli są statyczne. W związku z tym możemy buforować te dane podczas uruchamiania aplikacji.

Aby rozpocząć, utwórz nową klasę o nazwie StaticCache.cs w folderze CL .

Rysunek 2. Tworzenie StaticCache.vb klasy w folderze CL

Musimy dodać metodę, która ładuje dane podczas uruchamiania do odpowiedniego magazynu pamięci podręcznej, a także metody zwracające dane z tej pamięci podręcznej.

<System.ComponentModel.DataObject()> _
Public Class StaticCache
    Private Shared suppliers As Northwind.SuppliersDataTable = Nothing
    Public Shared Sub LoadStaticCache()
        ' Get suppliers - cache using a static member variable
        Dim suppliersBLL As New SuppliersBLL()
        suppliers = suppliersBLL.GetSuppliers()
    End Sub
    
    <DataObjectMethodAttribute(DataObjectMethodType.Select, True)> _
    Public Shared Function GetSuppliers() As Northwind.SuppliersDataTable
        Return suppliers
    End Function
End Class

Powyższy kod używa statycznej zmiennej suppliersskładowej , do przechowywania wyników z SuppliersBLL metody s GetSuppliers() klasy, która jest wywoływana LoadStaticCache() z metody. Metoda LoadStaticCache() ma być wywoływana podczas uruchamiania aplikacji. Po załadowaniu tych danych podczas uruchamiania aplikacji każda strona, która musi pracować z danymi dostawcy, może wywołać StaticCache metodę s GetSuppliers() klasy. W związku z tym wywołanie bazy danych w celu pobrania dostawców odbywa się tylko raz na początku aplikacji.

Zamiast używać statycznej zmiennej składowej jako magazynu pamięci podręcznej, moglibyśmy też użyć stanu aplikacji lub pamięci podręcznej danych. Poniższy kod przedstawia klasę przebudowaną do używania stanu aplikacji.

<System.ComponentModel.DataObject()> _
Public Class StaticCache
    Public Shared Sub LoadStaticCache()
        ' Get suppliers - cache using application state
        Dim suppliersBLL As New SuppliersBLL()
        HttpContext.Current.Application("key") = suppliers
    End Sub
    
    <DataObjectMethodAttribute(DataObjectMethodType.Select, True)> _
    Public Shared Function GetSuppliers() As Northwind.SuppliersDataTable
        Return TryCast(HttpContext.Current.Application("key"), _
            Northwind.SuppliersDataTable)
    End Function
End Class

W LoadStaticCache()systemie przechowywane są informacje o dostawcy w zmiennej aplikacji klucz. Jest zwracany jako odpowiedni typ (Northwind.SuppliersDataTable) z GetSuppliers(). Podczas gdy dostęp do stanu aplikacji można uzyskać w klasach code-behind stron ASP.NET przy użyciu metody Application("key"), w architekturze musimy użyć metody HttpContext.Current.Application("key"), aby uzyskać bieżący HttpContext.

Podobnie pamięć podręczna danych może być używana jako magazyn, jak widać w poniższym kodzie:

<System.ComponentModel.DataObject()> _
Public Class StaticCache
    Public Shared Sub LoadStaticCache()
        ' Get suppliers - cache using a static member variable
        Dim suppliersBLL As New SuppliersBLL()
        HttpRuntime.Cache.Insert("key", suppliers, Nothing, _
            Cache.NoAbsoluteExpiration, Cache.NoSlidingExpiration, _
            CacheItemPriority.NotRemovable, Nothing)
    End Sub
    <System.ComponentModel.DataObjectMethodAttribute_
    (System.ComponentModel.DataObjectMethodType.Select, True)> _
    Public Shared Function GetSuppliers() As Northwind.SuppliersDataTable
        Return TryCast(HttpRuntime.Cache("key"), Northwind.SuppliersDataTable)
    End Function
End Class

Aby dodać element do pamięci podręcznej danych bez wygaśnięcia na podstawie czasu, jako parametry wejściowe użyj wartości System.Web.Caching.Cache.NoAbsoluteExpiration oraz System.Web.Caching.Cache.NoSlidingExpiration. To szczególne przeciążenie metody pamięci podręcznej Insert danych zostało wybrane tak, abyśmy mogli określić priorytet elementu pamięci podręcznej. Priorytet służy do określania elementów do usunięcia z pamięci podręcznej, gdy dostępna pamięć się kończy. W tym miejscu użyjemy priorytetu NotRemovable, co gwarantuje, że ten element pamięci podręcznej nie zostanie przeszycony.

Uwaga / Notatka

Ten plik do pobrania samouczka implementuje StaticCache klasę przy użyciu podejścia statycznej zmiennej składowej. Kod technik stanu aplikacji i pamięci podręcznej danych jest dostępny w komentarzach w pliku klasy.

Krok 4. Wykonywanie kodu podczas uruchamiania aplikacji

Aby wykonać kod po pierwszym uruchomieniu aplikacji internetowej, musimy utworzyć specjalny plik o nazwie Global.asax. Ten plik może zawierać programy obsługi zdarzeń dla zdarzeń aplikacji, sesji i żądań. W tym miejscu można dodać kod, który będzie wykonywany za każdym razem, gdy aplikacja zostanie uruchomiona.

Global.asax Dodaj plik do katalogu głównego aplikacji internetowej, klikając prawym przyciskiem myszy nazwę projektu witryny internetowej w Eksploratorze rozwiązań programu Visual Studio i wybierając polecenie Dodaj nowy element. W oknie dialogowym Dodawanie nowego elementu wybierz typ elementu Global Application Class (Klasa aplikacji globalnej), a następnie kliknij przycisk Dodaj.

Uwaga / Notatka

Jeśli masz już plik Global.asax w projekcie, typ elementu Klasa aplikacji globalnej nie będzie wyświetlany w oknie dialogowym Dodawanie nowego elementu.

Rysunek 3: Dodaj Global.asax plik do katalogu głównego aplikacji internetowej (kliknij, aby wyświetlić obraz w pełnym rozmiarze)

Domyślny Global.asax szablon pliku zawiera pięć metod w tagu po stronie <script> serwera:

• Application_Start jest wykonywany po pierwszym uruchomieniu aplikacji internetowej
• Application_End jest uruchamiany, gdy aplikacja jest zamykana
• Application_Error jest wykonywany za każdym razem, gdy nieobsługiwany wyjątek osiągnie aplikację
• Session_Start wykonuje po utworzeniu nowej sesji
• Session_End jest uruchamiany, gdy sesja wygasła lub porzucona

Program Application_Start obsługi zdarzeń jest wywoływany tylko raz w cyklu życia aplikacji. Aplikacja uruchamia się po raz pierwszy, gdy zasób ASP.NET jest żądany przez aplikację, i działa aż do jej ponownego uruchomienia, co może nastąpić z powodu modyfikacji zawartości folderu /Bin, modyfikacji Global.asax, zmiany zawartości folderu App_Code, lub modyfikacji pliku Web.config, między innymi. Zapoznaj się z przeglądem cyklu życia aplikacji ASP.NET, aby uzyskać bardziej szczegółową dyskusję na temat cyklu życia aplikacji.

W tych samouczkach tylko do metody Application_Start musimy dodać kod, więc możesz swobodnie usunąć pozostałe. W Application_Startprogramie po prostu wywołaj StaticCache metodę klasy s LoadStaticCache() , która załaduje i zapisze w pamięci podręcznej informacje o dostawcy:

<%@ Application Language="VB" %>
<script runat="server">
    Sub Application_Start(ByVal sender As Object, ByVal e As EventArgs)
        StaticCache.LoadStaticCache()
    End Sub
</script>

To wszystko! Podczas uruchamiania aplikacji metoda LoadStaticCache() będzie pobierać informacje o dostawcy z BLL i przechowywać je w statycznej zmiennej członkowskiej (lub w jakimkolwiek magazynie pamięci podręcznej, którego używasz w klasie StaticCache). Aby zweryfikować to zachowanie, ustaw punkt przerwania w metodzie Application_Start i uruchom aplikację. Należy pamiętać, że punkt przerwania jest osiągany po uruchomieniu aplikacji. Jednak kolejne żądania nie powodują wykonania metody Application_Start.

Rysunek 4. Użyj punktu przerwania, aby sprawdzić, czy Application_Start procedura obsługi zdarzeń jest wykonywana (kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Uwaga / Notatka

Jeśli nie osiągniesz Application_Start punktu przerwania podczas pierwszego rozpoczęcia debugowania, jest to spowodowane tym, że aplikacja została już uruchomiona. Wymuś ponowne uruchomienie aplikacji, modyfikując pliki Global.asax lub Web.config , a następnie spróbuj ponownie. Możesz po prostu dodać (lub usunąć) pusty wiersz na końcu jednego z tych plików, aby szybko ponownie uruchomić aplikację.

Krok 5. Wyświetlanie buforowanych danych

W tym momencie StaticCache klasa ma wersję danych dostawcy buforowanych podczas uruchamiania aplikacji, do których można uzyskać dostęp za pośrednictwem metody GetSuppliers() . Aby pracować z tymi danymi z warstwy prezentacji, możemy użyć ObjectDataSource lub programowo wywołać StaticCache metodę s GetSuppliers() klasy z klasy ASP.NET strony za kodem. Przyjrzyjmy się użyciu kontrolek ObjectDataSource i GridView w celu wyświetlenia informacji o dostawcy w pamięci podręcznej.

Rozpocznij od otwarcia strony AtApplicationStartup.aspx w folderze Caching. Przeciągnij kontrolkę GridView z przybornika do projektanta, ustawiając właściwość ID na Suppliers. Następnie z tagu inteligentnego GridView wybierz pozycję utworzenia nowego ObjectDataSource o nazwie SuppliersCachedDataSource. Skonfiguruj obiekt ObjectDataSource, aby używać metody StaticCache klasy GetSuppliers().

Rysunek 5. Konfigurowanie obiektu ObjectDataSource do używania StaticCache klasy (kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Rysunek 6. Używanie GetSuppliers() metody do pobierania buforowanych danych dostawcy (kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Po ukończeniu pracy kreatora program Visual Studio automatycznie doda pola BoundFields dla każdego pola danych w programie SuppliersDataTable. Znaczniki deklaratywne GridView i ObjectDataSource powinny wyglądać podobnie do następujących:

<asp:GridView ID="Suppliers" runat="server" AutoGenerateColumns="False" 
    DataKeyNames="SupplierID" DataSourceID="SuppliersCachedDataSource" 
    EnableViewState="False">
    <Columns>
        <asp:BoundField DataField="SupplierID" HeaderText="SupplierID" 
            InsertVisible="False" ReadOnly="True" 
            SortExpression="SupplierID" />
        <asp:BoundField DataField="CompanyName" HeaderText="CompanyName" 
            SortExpression="CompanyName" />
        <asp:BoundField DataField="Address" HeaderText="Address" 
            SortExpression="Address" />
        <asp:BoundField DataField="City" HeaderText="City" 
            SortExpression="City" />
        <asp:BoundField DataField="Country" HeaderText="Country" 
            SortExpression="Country" />
        <asp:BoundField DataField="Phone" HeaderText="Phone" 
            SortExpression="Phone" />
    </Columns>
</asp:GridView>
<asp:ObjectDataSource ID="SuppliersCachedDataSource" runat="server" 
    OldValuesParameterFormatString="original_{0}"
    SelectMethod="GetSuppliers" TypeName="StaticCache" />

Rysunek 7 przedstawia stronę po wyświetleniu za pośrednictwem przeglądarki. Dane wyjściowe są takie same, gdybyśmy pobrali dane z klasy BLL SuppliersBLL , ale użycie StaticCache klasy zwraca dane dostawcy jako buforowane podczas uruchamiania aplikacji. Możesz ustawić punkty przerwania w metodzie StaticCache s klasy GetSuppliers() , aby zweryfikować to zachowanie.

Rysunek 7: Buforowane dane dostawcy są wyświetlane w kontrolce GridView (Kliknij, aby wyświetlić obraz w pełnym rozmiarze)

Podsumowanie

Prawie każdy model danych zawiera sporo danych statycznych, zwykle implementowanych w postaci tabel wyszukiwania. Ponieważ te informacje są statyczne, nie ma powodu, aby stale uzyskiwać dostęp do bazy danych za każdym razem, gdy te informacje muszą zostać wyświetlone. Ponadto, ze względu na swój statyczny charakter, podczas buforowania danych nie ma potrzeby ich wygaśnięcia. W tym samouczku pokazano, jak pobrać takie dane i buforować je w pamięci podręcznej danych, stanie aplikacji i za pomocą statycznej zmiennej składowej. Informacje te są buforowane podczas uruchamiania aplikacji i pozostają w niej przez cały okres istnienia aplikacji.

W tym samouczku i dwóch poprzednich przyjrzeliśmy się buforowaniu danych przez cały okres istnienia aplikacji, a także korzystaniu z wygaśnięcia opartego na czasie. Jednak w przypadku buforowania danych bazy danych wygaśnięcie na podstawie czasu może być nie do końca idealne. Zamiast okresowo opróżniać pamięć podręczną, optymalne byłoby wykluczenie buforowanego elementu tylko wtedy, gdy bazowe dane bazy danych zostaną zmodyfikowane. Jest to idealne rozwiązanie, korzystając z zależności pamięci podręcznej SQL, które przeanalizujemy w następnym samouczku.

Szczęśliwe programowanie!

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łówni recenzenci tego samouczka to Teresa Murphy i Zack Jones. Chcesz przejrzeć nadchodzące artykuły MSDN? Jeśli tak, napisz do mnie na adres mitchell@4GuysFromRolla.com.

PoprzedniNastępny