Caching von Benutzersteuerelementen in .NET

Die Designer von ASP.NET haben daran gedacht, dass nicht jede Methode voraussehbar ist, die festlegt, welche gecachte Version eines Steuerelements ein Entwickler womöglich verwenden möchte. Daher haben sie VaryByCustom hinzugefügt. Dies ermöglicht es beispielsweise, bei einer Kopie im Cache unterschiedliche Informationen aus einem Benutzerprofil anzuzeigen. Das könnte etwa eine Liste der Vorteile sein, die ein Mitglied einer bestimmten Klasse erhalten sollte.

Ein Steuerelement, welches diese Vorteile anzeigt, müsste wissen, welcher Klasse dieser Benutzer angehört. Aber diese Information wird wahrscheinlich nicht im Querystring oder einem Teil des Formular-Post enthalten sein. Um die verschiedenen gecachten Kopien des Steuerelements kontrollieren zu können, muss man daher auf das Attribut VaryByCustom zurückgreifen und – in der globalen Klasse – ein Mitglied GetVaryByCustomString() einrichten.

Die Mitgliedsfunktion verwendet zwei Parameter. Der erste ist der HttpContext derjenigen Anfrage, die den Aufruf ausgelöst hat. Dies ist notwendig, falls es Variablen in der Session gibt, die berücksichtigt werden müssen, zum Beispiel ein Benutzerprofil-Objekt. Der zweite Parameter ist der Argument-String, der als Wert für das Attribut VaryByCustom im Steuerelement übergeben wird. Dieser String ist der vollständige Wert, also nicht aufgeteilt oder in sonst irgendeiner Weise aufbereitet. Der erwartete Rückgabewert ist ein String, der diese bestimmte Instanz der gecachten Kopie des Steuerelements eindeutig identifiziert.

Der Programmcode sollte das eingehende Argument auswerten und den entsprechenden Return-String liefern. Der Code in Listing A sucht zum Beispiel nach der Session des Benutzers für die im Attribut VaryByCustom aufgeführten Variablen und gibt die Werte dieser Session als Teil eines Custom-Strings zurück:

Listing A

Den Cache aufräumen

In den meisten Fällen dürfte die eingerichtete Cachingfunktion genau das sein, was man braucht. Es kann aber auch vorkommen, dass man nicht so lange darauf warten möchte, bis der Cache geleert wird, vor allem wenn man gerade beim Debuggen ist. Aus diesem Grund ist es möglich, den Ausgabe-Cache für ein Steuerelement (so wie für eine Seite) zu leeren. Die entsprechende Methode ist Response.RemoveOutputCacheItem(), mit der ein Element aus dem Cache entfernt wird. Die Sache hat allerdings einen Haken: RemoveOutputCacheItem übernimmt nur einen Parameter, nämlich den Pfad der zu entfernenden Elemente. Obwohl diese statische Methode dem Namen nach vorgibt, nur ein Element zu löschen, entfernt sie in Wirklichkeit alle gecachten Kopien des Steuerelements (oder der Seite) für einen bestimmten Pfad.

Das stellt normalerweise kein Problem dar, wenn man Elemente zu Debuggingzwecken entfernt. Es kann aber zu einer echten Herausforderung werden, sobald man die Funktion eigentlich dazu verwenden will, eine einzelne Version des Steuerelements zu entfernen. Für dieses Steuerelement kann es Hunderte unterschiedlich gecachte Kopien geben, von denen dann jede einzelne wiederhergestellt werden müsste.