Sortie de mise en cache d'un contrôle personnalisé (contrôle serveur)

Question

J'ai trouvé des indices sur la mise en cache d'un contrôle serveur, mais je n'ai pas encore trouvé de réponse définitive à cette question: la sortie d'un contrôle serveur peut-elle être mise en cache? les contrôles utilisateur sont mis en cache)? Les suggestions que j'ai rencontrées impliquent la mise en cache des données (pas la vraie mise en cache de sortie), ou suggèrent de définir les options de response.cache. Idéalement, je voudrais être en mesure de faire glisser un contrôle du serveur à la page et définir des propriétés avec le même nom que la directive OutputCache:

Exemple:

<cc1:MyCustomControl ID="ctl1" runat="server" CacheDuration="200" VaryByCustom="user" /> 

j'allais creuser dans la cadre pour voir comment la mise en cache de sortie fonctionne vraiment, mais espérait trouver des informations pour me lancer. De ma compréhension limitée, l'analyseur décide si une commande page/usercontrol est mise en cache ou non. Puisque les contrôles serveur ne sont pas analysés, il n'y aurait aucun moyen d'arrêter l'exécution du code. Je suppose que je pourrais initialiser un booléen "IsInCache" et m'assurer que toutes les méthodes vérifient cette variable avant d'exécuter le code. Cela n'éliminerait pas entièrement l'exécution du contrôle serveur, mais cela pourrait améliorer les performances en évitant les appels à la base de données et en liant les données aux contrôles.

J'utilise toujours .NET 3.5 et n'ai pas eu beaucoup de temps pour explorer le modèle de fournisseur OutputCache dans .NET 4.0. Peut-être qu'il y a une solution dans la dernière version du framework?

Des pensées?

Answer 1

Je cherchais aussi cela et je me suis dit que j'ajouterais la solution à cette page depuis qu'elle est apparue dans ma recherche sur le web. Il existe un attribut appelé PartialCaching qui est appliqué au contrôle côté serveur/personnalisé pour obtenir le même effet que la directive OutputCache utilisée dans les modèles ascx et aspx. Il prend également les mêmes paramètres (VaryByParameter, etc.). Par exemple:

ce le même que l'attribut modèle

[PartialCaching(1000, "foo", null, null)] 
public class ClientScriptVariableBlock : Control { 
    ... 
} 

La plomberie ASP traite, de sorte que le résultat final est le même. Ceci est utile (dans mon cas) car je peux créer des contrôles serveur communs en dehors du projet web lui-même qui peuvent être mis en cache. Les modèles ASCX ne fonctionnent pas très bien dans les assemblages externes :)