Zwischenspeichern von Daten beim Anwendungsstart (C#)

von Scott Mitchell

PDF herunterladen

In jeder Webanwendung werden einige Daten häufig verwendet, und einige Daten werden selten verwendet. Wir können die Leistung unserer ASP.NET Anwendung verbessern, indem wir die häufig verwendeten Daten im Voraus laden, eine Technik, die als Caching bezeichnet wird. In diesem Tutorial wird ein Ansatz für das proaktive Laden veranschaulicht, bei dem Daten beim Anwendungsstart in den Cache geladen werden.

Einführung

In den beiden vorherigen Tutorials wurde das Zwischenspeichern von Daten in den Ebenen "Präsentation" und "Zwischenspeichern" behandelt. Unter Zwischenspeichern von Daten mit ObjectDataSource haben wir die Verwendung der Zwischenspeicherungsfeatures von ObjectDataSource zum Zwischenspeichern von Daten in der Präsentationsebene untersucht. Das Zwischenspeichern von Daten in der Architektur hat das Zwischenspeichern in einer neuen, separaten Cacheebene untersucht. In beiden Tutorials wurde das reaktive Laden beim Arbeiten mit dem Datencache verwendet. Beim reaktiven Laden überprüft das System jedes Mal, wenn die Daten angefordert werden, zuerst, ob sie sich im Cache befinden. Andernfalls werden die Daten aus der Ursprungsquelle, z. B. der Datenbank, abgerufen und dann im Cache gespeichert. Der Standard Vorteil des reaktiven Ladens ist die einfache Implementierung. Einer der Nachteile ist die ungleichmäßige Leistung der Anforderungen. Stellen Sie sich eine Seite vor, auf der die Cacheebene aus dem vorherigen Tutorial zum Anzeigen von Produktinformationen verwendet wird. Wenn diese Seite zum ersten Mal besucht oder zum ersten Mal aufgerufen wird, nachdem die zwischengespeicherten Daten aufgrund von Speichereinschränkungen oder dem angegebenen Ablauf entfernt wurden, müssen die Daten aus der Datenbank abgerufen werden. Daher dauern diese Benutzeranforderungen länger als Benutzeranforderungen, die vom Cache verarbeitet werden können.

Proaktives Laden bietet eine alternative Cacheverwaltungsstrategie, die die Leistung zwischen Anforderungen glättet, indem die zwischengespeicherten Daten geladen werden, bevor sie benötigt werden. In der Regel wird beim proaktiven Laden ein Prozess verwendet, der entweder regelmäßig überprüft oder benachrichtigt wird, wenn eine Aktualisierung der zugrunde liegenden Daten erfolgt ist. Dieser Prozess aktualisiert dann den Cache, um ihn aktuell zu halten. Proaktives Laden ist besonders nützlich, wenn die zugrunde liegenden Daten aus einer langsamen Datenbankverbindung, einem Webdienst oder einer anderen besonders trägen Datenquelle stammen. Dieser Ansatz für proaktives Laden ist jedoch schwieriger zu implementieren, da er das Erstellen, Verwalten und Bereitstellen eines Prozesses erfordert, um nach Änderungen zu suchen und den Cache zu aktualisieren.

Eine weitere Variante des proaktiven Ladens und des Typs, den wir in diesem Tutorial untersuchen werden, ist das Laden von Daten in den Cache beim Anwendungsstart. Dieser Ansatz ist besonders nützlich für das Zwischenspeichern statischer Daten, z. B. der Datensätze in Datenbank-Nachschlagetabellen.

Hinweis

Einen ausführlicheren Blick auf die Unterschiede zwischen proaktivem und reaktivem Laden sowie Auflisten von Vor-, Nachteilen und Implementierungsempfehlungen finden Sie im Abschnitt Verwalten der Inhalte eines Caches des Handbuchs zur Cachearchitektur für .NET Framework-Anwendungen.

Schritt 1: Bestimmen, welche Daten beim Anwendungsstart zwischengespeichert werden sollen

Die In den vorherigen beiden Tutorials untersuchten Zwischenspeicherungsbeispiele mit reaktivem Laden funktionieren gut mit Daten, die sich regelmäßig ändern können und die Generierung nicht exorbitant lange dauert. Wenn sich die zwischengespeicherten Daten jedoch nie ändern, ist der Ablauf, der beim reaktiven Laden verwendet wird, überflüssig. Wenn die Generierung der zwischengespeicherten Daten sehr lange dauert, müssen die Benutzer, deren Anforderungen den Cache als leer finden, lange warten, während die zugrunde liegenden Daten abgerufen werden. Erwägen Sie das Zwischenspeichern statischer Daten und Daten, deren Generierung beim Anwendungsstart außergewöhnlich lange dauert.

Datenbanken verfügen zwar über viele dynamische, sich häufig ändernde Werte, aber die meisten verfügen auch über eine angemessene Menge statischer Daten. Beispielsweise verfügen praktisch alle Datenmodelle über eine oder mehrere Spalten, die einen bestimmten Wert aus einem festen Satz von Auswahlmöglichkeiten enthalten. Eine Patients Datenbanktabelle kann über eine PrimaryLanguage Spalte verfügen, deren Wertesatz Englisch, Spanisch, Französisch, Russisch, Japanisch usw. sein kann. Häufig werden diese Spaltentypen mithilfe von Nachschlagetabellen implementiert. Anstatt die Zeichenfolge englisch oder französisch in der Tabelle zu speichern, wird eine zweite Tabelle erstellt, die in der Patients Regel zwei Spalten - einen eindeutigen Bezeichner und eine Zeichenfolgenbeschreibung - mit einem Datensatz für jeden möglichen Wert enthält. Die PrimaryLanguage Spalte in der Patients Tabelle speichert den entsprechenden eindeutigen Bezeichner in der Nachschlagetabelle. In Abbildung 1 ist die Hauptsprache des Patienten John Doe Englisch, während Ed Johnson russisch ist.

Abbildung 1: Die Languages Tabelle ist eine von der Patients Tabelle verwendete Nachschlagetabelle.

Die Benutzeroberfläche zum Bearbeiten oder Erstellen eines neuen Patienten enthält eine Dropdownliste der zulässigen Sprachen, die von den Datensätzen in der Languages Tabelle aufgefüllt werden. Ohne Zwischenspeicherung muss das System bei jedem Besuch dieser Schnittstelle die Languages Tabelle abfragen. Dies ist verschwenderisch und unnötig, da sich die Werte der Nachschlagetabelle sehr selten ändern, wenn überhaupt.

Wir konnten die Languages Daten mit denselben reaktiven Ladetechniken zwischenspeichern, die in den vorherigen Tutorials untersucht wurden. Beim reaktiven Laden wird jedoch ein zeitbasierter Ablauf verwendet, der für statische Nachschlagetabellendaten nicht benötigt wird. Während das Zwischenspeichern mit reaktivem Laden besser wäre als gar kein Zwischenspeichern, wäre es am besten, die Nachschlagetabellendaten beim Anwendungsstart proaktiv in den Cache zu laden.

In diesem Tutorial erfahren Sie, wie Sie Nachschlagetabellendaten und andere statische Informationen zwischenspeichern.

Schritt 2: Untersuchen der verschiedenen Möglichkeiten zum Zwischenspeichern von Daten

Informationen können programmgesteuert in einer ASP.NET-Anwendung mit einer Vielzahl von Ansätzen zwischengespeichert werden. In den vorherigen Tutorials haben wir bereits erfahren, wie Sie den Datencache verwenden. Alternativ können Objekte mithilfe statischer Member oder des Anwendungszustands programmgesteuert zwischengespeichert werden.

Wenn Sie mit einer Klasse arbeiten, muss die Klasse in der Regel zuerst instanziiert werden, bevor auf ihre Member zugegriffen werden kann. Um beispielsweise eine Methode aus einer der Klassen in unserer Business Logic Layer-Klasse aufzurufen, müssen wir zunächst eine instance der -Klasse erstellen:

ProductsBLL productsAPI = new ProductsBLL();
productsAPI.SomeMethod();
productsAPI.SomeProperty = "Hello, World!";

Bevor wir SomeMethod aufrufen oder mit SomeProperty arbeiten können, müssen wir zunächst mithilfe des Schlüsselwort (keyword) eine instance der -Klasse new erstellen. SomeMethod und SomeProperty sind einem bestimmten instance zugeordnet. Die Lebensdauer dieser Member ist an die Lebensdauer des zugeordneten Objekts gebunden. Statische Member hingegen sind Variablen, Eigenschaften und Methoden, die von allen Instanzen der -Klasse gemeinsam verwendet werden und folglich eine Lebensdauer haben, die so lange wie die Klasse ist. Statische Member werden durch die Schlüsselwort (keyword) staticbezeichnet.

Zusätzlich zu statischen Membern können Daten mithilfe des Anwendungszustands zwischengespeichert werden. Jede ASP.NET Anwendung verwaltet eine Name/Wert-Sammlung, die für alle Benutzer und Seiten der Anwendung freigegeben wird. Auf diese Auflistung kann mithilfe der -Eigenschaft der HttpContext -KlasseApplication zugegriffen werden, und die CodeBehind-Klasse einer ASP.NET Seite wie folgt verwendet werden:

Application["key"] = value;
object value = Application["key"];

Der Datencache bietet eine viel umfangreichere API für das Zwischenspeichern von Daten und stellt Mechanismen für zeit- und abhängigkeitsbasierte Ablaufzeiten, Cacheelementprioritäten usw. bereit. Bei statischen Membern und dem Anwendungszustand müssen solche Features vom Seitenentwickler manuell hinzugefügt werden. Beim Zwischenspeichern von Daten beim Anwendungsstart für die Lebensdauer der Anwendung sind die Vorteile des Datencaches jedoch moot. In diesem Tutorial sehen wir uns Code an, der alle drei Techniken zum Zwischenspeichern statischer Daten verwendet.

Schritt 3: Zwischenspeichern derSuppliersTabellendaten

Die bisher implementierten Northwind-Datenbanktabellen enthalten keine herkömmlichen Nachschlagetabellen. Die vier DataTables, die in unserem DAL implementiert wurden, sind alle Modelltabellen, deren Werte nicht statisch sind. Anstatt die Zeit zu verwenden, um dem DAL eine neue DataTable und dann eine neue Klasse und Methoden zur BLL hinzuzufügen, sollten wir in diesem Tutorial einfach so tun, als wären die Daten der Suppliers Tabelle statisch. Daher könnten wir diese Daten beim Anwendungsstart zwischenspeichern.

Erstellen Sie zunächst eine neue Klasse namens StaticCache.cs im CL Ordner.

Abbildung 2: Erstellen der StaticCache.cs Klasse im CL Ordner

Wir müssen eine Methode hinzufügen, die die Daten beim Start in den entsprechenden Cachespeicher lädt, sowie Methoden, die Daten aus diesem Cache zurückgeben.

[System.ComponentModel.DataObject]
public class StaticCache
{
    private static Northwind.SuppliersDataTable suppliers = null;
    public static void LoadStaticCache()
    {
        // Get suppliers - cache using a static member variable
        SuppliersBLL suppliersBLL = new SuppliersBLL();
        suppliers = suppliersBLL.GetSuppliers();
    }
    [DataObjectMethodAttribute(DataObjectMethodType.Select, true)]
    public static Northwind.SuppliersDataTable GetSuppliers()
    {
        return suppliers;
    }
}

Der obige Code verwendet die statische Membervariable , suppliersum die Ergebnisse der -Methode der SuppliersBLL -Klasse GetSuppliers() zu speichern, die von der LoadStaticCache() -Methode aufgerufen wird. Die LoadStaticCache() -Methode soll während des Anwendungsstarts aufgerufen werden. Nachdem diese Daten beim Anwendungsstart geladen wurden, kann jede Seite, die mit Lieferantendaten arbeiten muss, die -Methode der StaticCacheGetSuppliers() -Klasse aufrufen. Daher erfolgt der Aufruf der Datenbank zum Abrufen der Lieferanten nur einmal beim Anwendungsstart.

Anstatt eine statische Membervariable als Cachespeicher zu verwenden, hätten wir alternativ den Anwendungszustand oder den Datencache verwenden können. Der folgende Code zeigt die Klasse, die für die Verwendung des Anwendungszustands umgerüstet wurde:

[System.ComponentModel.DataObject]
public class StaticCache
{
    public static void LoadStaticCache()
    {
        // Get suppliers - cache using application state
        SuppliersBLL suppliersBLL = new SuppliersBLL();
        HttpContext.Current.Application["key"] = suppliersBLL.GetSuppliers();
    }
    [DataObjectMethodAttribute(DataObjectMethodType.Select, true)]
    public static Northwind.SuppliersDataTable GetSuppliers()
    {
        return HttpContext.Current.Application["key"] as Northwind.SuppliersDataTable;
    }
}

In LoadStaticCache()werden die Lieferanteninformationen im Anwendungsvariablenschlüssel gespeichert. Sie wird als geeigneter Typ (Northwind.SuppliersDataTable) von GetSuppliers()zurückgegeben. Während der Anwendungszustand in den CodeBehind-Klassen von ASP.NET Seiten mit Application["key"]zugegriffen werden kann, müssen wir in der Architektur verwenden HttpContext.Current.Application["key"] , um den aktuellen HttpContextabzurufen.

Ebenso kann der Datencache als Cachespeicher verwendet werden, wie der folgende Code zeigt:

[System.ComponentModel.DataObject]
public class StaticCache
{
    public static void LoadStaticCache()
    {
        // Get suppliers - cache using the data cache
        SuppliersBLL suppliersBLL = new SuppliersBLL();
        HttpRuntime.Cache.Insert(
          /* key */                "key", 
          /* value */              suppliers, 
          /* dependencies */       null, 
          /* absoluteExpiration */ Cache.NoAbsoluteExpiration, 
          /* slidingExpiration */  Cache.NoSlidingExpiration, 
          /* priority */           CacheItemPriority.NotRemovable, 
          /* onRemoveCallback */   null);
    }
    [DataObjectMethodAttribute(DataObjectMethodType.Select, true)]
    public static Northwind.SuppliersDataTable GetSuppliers()
    {
        return HttpRuntime.Cache["key"] as Northwind.SuppliersDataTable;
    }
}

Um dem Datencache ein Element ohne zeitbasierten Ablauf hinzuzufügen, verwenden Sie die System.Web.Caching.Cache.NoAbsoluteExpiration Werte und System.Web.Caching.Cache.NoSlidingExpiration als Eingabeparameter. Diese spezielle Überladung der -Methode des Datencaches Insert wurde ausgewählt, damit wir die Priorität des Cacheelements angeben konnten. Die Priorität wird verwendet, um zu bestimmen, welche Elemente aus dem Cache entfernt werden sollen, wenn der verfügbare Arbeitsspeicher knapp ist. Hier verwenden wir die Priorität NotRemovable, die sicherstellt, dass dieses Cacheelement nicht gelöscht wird.

Hinweis

Der Download dieses Tutorials implementiert die StaticCache -Klasse mithilfe des Ansatzes für statische Membervariablen. Der Code für die Anwendungsstatus- und Datencachetechniken ist in den Kommentaren in der Klassendatei verfügbar.

Schritt 4: Ausführen von Code beim Anwendungsstart

Um Code auszuführen, wenn eine Webanwendung zum ersten Mal gestartet wird, müssen wir eine spezielle Datei mit dem Namen Global.asaxerstellen. Diese Datei kann Ereignishandler für Ereignisse auf Anwendungs-, Sitzungs- und Anforderungsebene enthalten, und hier können wir Code hinzufügen, der beim Starten der Anwendung ausgeführt wird.

Fügen Sie die Global.asax Datei zum Stammverzeichnis Ihrer Webanwendung hinzu, indem Sie im visual Studio-Projektmappen-Explorer mit der rechten Maustaste auf den Namen des Websiteprojekts klicken und Neues Element hinzufügen auswählen. Wählen Sie im Dialogfeld Neues Element hinzufügen den Elementtyp Globale Anwendungsklasse aus, und klicken Sie dann auf die Schaltfläche Hinzufügen.

Hinweis

Wenn Sie bereits über eine Global.asax Datei in Ihrem Projekt verfügen, wird der Elementtyp Globale Anwendungsklasse nicht im Dialogfeld Neues Element hinzufügen aufgeführt.

Abbildung 3: Hinzufügen der Global.asax Datei zum Stammverzeichnis Ihrer Webanwendung (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Die Standarddateivorlage Global.asax enthält fünf Methoden in einem serverseitigen <script> Tag:

• Application_Start wird ausgeführt, wenn die Webanwendung zum ersten Mal gestartet wird.
• Application_End wird ausgeführt, wenn die Anwendung heruntergefahren wird
• Application_Error wird immer ausgeführt, wenn eine nicht behandelte Ausnahme die Anwendung erreicht.
• Session_Start wird ausgeführt, wenn eine neue Sitzung erstellt wird.
• Session_End wird ausgeführt, wenn eine Sitzung abgelaufen oder abgebrochen wird

Der Application_Start Ereignishandler wird während des Lebenszyklus einer Anwendung nur einmal aufgerufen. Die Anwendung startet, wenn eine ASP.NET Ressource zum ersten Mal von der Anwendung angefordert wird, und wird weiterhin ausgeführt, bis die Anwendung neu gestartet wird. Dies kann unter anderem durch Ändern des Inhalts des /Bin Ordners, Ändern Global.asaxdes Inhalts im App_Code Ordner oder Ändern der Web.config Datei geschehen. Ausführlichere Informationen zum Anwendungslebenszyklus finden Sie unter ASP.NET Übersicht über den Anwendungslebenszyklus.

Für diese Tutorials müssen wir der Application_Start -Methode nur Code hinzufügen, also können Sie die anderen entfernen. Rufen Application_StartSie in einfach die -Methode der StaticCache -Klasse LoadStaticCache() auf, die die Lieferanteninformationen lädt und zwischenspeichert:

<%@ Application Language="C#" %>
<script runat="server">
    void Application_Start(object sender, EventArgs e) 
    {
        StaticCache.LoadStaticCache();
    }
</script>

Das war es schon! Beim Anwendungsstart ruft die LoadStaticCache() Methode die Lieferanteninformationen aus der BLL ab und speichert sie in einer statischen Membervariable (oder einem Cachespeicher, den Sie in der StaticCache Klasse verwendet haben). Um dieses Verhalten zu überprüfen, legen Sie einen Haltepunkt in der Application_Start -Methode fest, und führen Sie Ihre Anwendung aus. Beachten Sie, dass der Haltepunkt beim Starten der Anwendung erreicht wird. Nachfolgende Anforderungen führen jedoch nicht dazu, dass die Application_Start -Methode ausgeführt wird.

Abbildung 4: Verwenden eines Haltepunkts, um zu überprüfen, ob der Application_Start Ereignishandler ausgeführt wird (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Hinweis

Wenn Sie den Haltepunkt beim ersten Starten des Application_Start Debuggens nicht erreichen, liegt dies daran, dass Ihre Anwendung bereits gestartet wurde. Erzwingen Sie den Neustart der Anwendung, indem Sie die Global.asax Dateien oder Web.config ändern, und versuchen Sie es dann erneut. Sie können einfach eine leere Zeile am Ende einer dieser Dateien hinzufügen (oder entfernen), um die Anwendung schnell neu zu starten.

Schritt 5: Anzeigen der zwischengespeicherten Daten

An diesem Punkt verfügt die StaticCache -Klasse über eine Version der Lieferantendaten, die beim Anwendungsstart zwischengespeichert werden und auf die über die GetSuppliers() -Methode zugegriffen werden kann. Um mit diesen Daten aus der Präsentationsebene zu arbeiten, können wir eine ObjectDataSource verwenden oder die -Methode der StaticCache Klasse GetSuppliers() programmgesteuert aus der CodeBehind-Klasse einer ASP.NET Seite aufrufen. Sehen wir uns die Verwendung der ObjectDataSource- und GridView-Steuerelemente an, um die zwischengespeicherten Lieferanteninformationen anzuzeigen.

Öffnen Sie zunächst die AtApplicationStartup.aspx Seite im Caching Ordner. Ziehen Sie ein GridView-Objekt aus der Toolbox auf den Designer, und legen Sie die ID -Eigenschaft auf fest Suppliers. Wählen Sie als Nächstes aus dem Smarttag von GridView aus, um eine neue ObjectDataSource mit dem Namen SuppliersCachedDataSourcezu erstellen. Konfigurieren Sie objectDataSource für die Verwendung der -Methode der StaticCacheGetSuppliers() -Klasse.

Abbildung 5: Konfigurieren der ObjectDataSource für die Verwendung der StaticCache -Klasse (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Abbildung 6: Verwenden der GetSuppliers() -Methode zum Abrufen der zwischengespeicherten Lieferantendaten (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Nach Abschluss des Assistenten fügt Visual Studio automatisch BoundFields für jedes der Datenfelder in SuppliersDataTablehinzu. Das deklarative Markup von GridView und ObjectDataSource sollte in etwa wie folgt aussehen:

<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" />

Abbildung 7 zeigt die Seite, wenn sie über einen Browser angezeigt wird. Die Ausgabe ist identisch, wenn wir die Daten aus der BLL-Klasse SuppliersBLL abgerufen haben, aber mithilfe der StaticCache -Klasse werden die Lieferantendaten zurückgegeben, die beim Anwendungsstart zwischengespeichert wurden. Sie können Haltepunkte in der -Methode der StaticCache -Klasse GetSuppliers() festlegen, um dieses Verhalten zu überprüfen.

Abbildung 7: Die zwischengespeicherten Lieferantendaten werden in einem GridView-Objekt angezeigt (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Zusammenfassung

Die meisten Datenmodelle enthalten eine angemessene Menge statischer Daten, die in der Regel in Form von Nachschlagetabellen implementiert werden. Da diese Informationen statisch sind, gibt es keinen Grund, jedes Mal, wenn diese Informationen angezeigt werden müssen, kontinuierlich auf die Datenbank zuzugreifen. Darüber hinaus ist aufgrund ihrer statischen Natur beim Zwischenspeichern der Daten kein Ablauf erforderlich. In diesem Tutorial haben wir erfahren, wie Sie diese Daten im Datencache, anwendungszustand und über eine statische Membervariable zwischenspeichern. Diese Informationen werden beim Anwendungsstart zwischengespeichert und verbleiben während der gesamten Lebensdauer der Anwendung im Cache.

In diesem tutorial und den letzten beiden haben wir uns mit dem Zwischenspeichern von Daten für die Dauer der Lebensdauer der Anwendung sowie mit zeitbasierten Ablaufvorgängen befasst. Beim Zwischenspeichern von Datenbankdaten kann ein zeitbasierter Ablauf jedoch weniger als ideal sein. Anstatt den Cache regelmäßig zu leeren, wäre es optimal, das zwischengespeicherte Element nur zu entfernen, wenn die zugrunde liegenden Datenbankdaten geändert werden. Dies ist durch die Verwendung von SQL-Cacheabhängigkeiten möglich, die wir in unserem nächsten Tutorial untersuchen werden.

Viel Spaß beim Programmieren!

Zum Autor

Scott Mitchell, Autor von sieben ASP/ASP.NET-Büchern und Gründer von 4GuysFromRolla.com, arbeitet seit 1998 mit Microsoft-Webtechnologien. Scott arbeitet als unabhängiger Berater, Trainer und Autor. Sein neuestes Buch ist Sams Teach Yourself ASP.NET 2.0 in 24 Hours. Er kann unter mitchell@4GuysFromRolla.comoder über seinen Blog erreicht werden, der unter http://ScottOnWriting.NETzu finden ist.

Besonderer Dank an

Diese Tutorialreihe wurde von vielen hilfreichen Prüfern überprüft. Hauptprüfer für dieses Tutorial waren Teresa Murphy und Zack Jones. Möchten Sie meine bevorstehenden MSDN-Artikel lesen? Wenn dies der Fall ist, legen Sie eine Zeile unter abmitchell@4GuysFromRolla.com.

ZurückWeiter