Série de conférences ASP (9) Définition de la portée de l'objet
Auteur：Eve Cole
Date de mise à jour：2009-05-30 19:59:07
La portée d'un objet détermine quels scripts peuvent utiliser l'objet. Par défaut, lorsque vous créez une instance d'objet, l'objet a une portée de page. Toute commande de script au sein de la même page ASP peut utiliser l'objet de portée page ; l'objet est libéré lorsque la page ASP est renvoyée au client. Pour la plupart des objets, la portée recommandée est la portée de la page. Vous pouvez modifier la portée d'un objet afin qu'il puisse être utilisé par des scripts sur d'autres pages. Cette rubrique explique comment utiliser des objets de portée page et comment modifier la portée d'un objet.
Utilisation d'objets de portée page Les objets créés avec Server.CreateObject sur une page ASP existent pendant toute la durée de vie de la page. L'objet est accessible à toutes les commandes de script pour la page et est libéré lorsque ASP a terminé le traitement de la page. Par conséquent, l’objet a la portée ou la durée de vie de la page.
Lors de la programmation avec Visual Basic ou VBScript, veillez à ne pas libérer l'objet tant qu'ASP n'a pas fini de traiter la page. Par exemple, l'instruction suivante est souvent utilisée pour libérer un objet en attribuant à la variable objet la valeur Nothing :
Définir monObj = Rien
Si vous incluez cette instruction dans une page ASP, toute tentative d'utilisation de myObj renverra un code d'erreur attendu. Mais en interne, ASP conserve toujours une référence à l'objet même après sa publication. Lorsque vous ne pouvez pas utiliser un objet dans un script, les ressources de l'objet ne sont pas libérées tant qu'ASP n'a pas fini de traiter la page. De même, si vous libérez l'objet en créant une autre instance d'objet et en l'attribuant à une variable d'objet déjà utilisée, ASP conserve une référence à l'instance d'objet d'origine. Pour la plupart des scripts, la création de plusieurs objets peut ne pas poser de problèmes, mais si les objets utilisent des ressources partagées, telles que des connexions à une base de données, des problèmes peuvent survenir.
Étant donné que les objets ont une portée de page, ne comptez pas sur la libération manuelle des objets. Par exemple, la boucle suivante crée 1001 objets Connection, qui seront capables d'ouvrir la plupart des connexions même vers un grand serveur SQL :
<%
Pour I = 0 à 1000
Définir Conn = Server.CreateObject("ADODB.Connection")
Conn.Open "chaîne de connexion"
Suivant
%>
En général, vous devriez éviter de créer des objets dans une boucle. Si cela est inévitable, vous devez libérer manuellement les ressources utilisées par l'objet. Si l'objet Connection n'est créé qu'une seule fois et que la connexion physique à la ressource de données est ouverte et fermée dans chaque boucle, alors l'exemple ci-dessus fonctionnera normalement :
<%
Définir Conn = Server.CreateObject("ADODB.Connection")
Pour I = 0 à 1000
Conn.Open "chaîne de connexion"
Conn.Fermer
Suivant
%>
Donner une portée de session aux objets Dans une application, un objet de portée session est créé pour chaque nouvelle session et est publié une fois la session terminée. Il existe donc un objet pour chaque session active. La portée de session est utilisée pour les objets appelés à partir de plusieurs scripts, mais qui n'affectent qu'une seule session utilisateur. Vous pouvez attribuer une portée de session d'objet uniquement lorsque cela est nécessaire. Si vous devez utiliser la portée de session, vous devez comprendre le modèle de thread du composant qui fournit l'objet, car il affecte les performances et l'environnement de sécurité de l'objet. Pour plus d’informations, consultez « Informations avancées : problèmes de performances » dans cette rubrique.
Pour attribuer une portée de session à un objet, stockez l'objet dans l'objet intégré Session ASP. Vous pouvez soit utiliser la balise <OBJECT> dans le fichier Global.asa, soit utiliser la méthode Server.CreateObject sur la page ASP pour créer une session. objet de portée. Instance d’objet de domaine.
Dans le fichier Global.asa, vous pouvez utiliser la balise ;OBJECT> qui étend l'attribut RUNAT (doit être défini sur Sever) et l'attribut SCOPE (doit être défini sur Session). L'exemple suivant crée une instance de l'objet Ad Rotator au niveau de la session :
<OBJECT RUNAT=Server SCOPE=Session ID=MyAd PROGID="MSWC.Adrotator">
</OBJET>
Une fois que vous avez stocké un objet dans l'objet Session, vous pouvez accéder à l'objet à partir de n'importe quelle page de l'application. L'instruction suivante utilise l'instance d'objet créée par la balise <OBJECT> dans l'exemple précédent :
<%= MyAd.GetAdvertisement("addata.txt") %>
Sur une page ASP, vous pouvez également utiliser la méthode Server.CreateObject pour stocker des objets dans l'objet intégré Session. L'exemple suivant stocke une instance de l'objet Ad Rotator dans l'objet Session.
<% Set Session("MyAd") = Server.CreateObject("MSWC.Adrotator") %>
Pour afficher une annonce, vous devez d'abord obtenir une instance de l'objet Ad Rotator stockée dans l'objet Session, puis appeler une méthode pour afficher l'objet :
<% Définir MonAnnonce = Session("MonAnnonce") %>
<%= MyAd.GetAdvertisement("addata.txt") %>
ASP ne crée pas d'instance d'un objet déclaré avec la balise <OBJECT> tant qu'il n'est pas référencé par une commande de script dans un fichier .asp. La méthode Server.CreateObject crée immédiatement une instance de l'objet. Par conséquent, il est préférable d'utiliser la balise <OBJECT> plutôt que la propriété Server.CreateObject pour les objets de portée session.
Donner une portée d'application à un objet
Un objet de portée application est une instance unique d’un objet créé au démarrage de l’application. Cet objet est partagé par toutes les requêtes clients. Ce n'est que dans de rares cas que vous devez attribuer une portée d'application à un objet. Certains objets utilitaires, tels que les compteurs, etc., peuvent nécessiter une portée d'application. Mais en général, vous pouvez utiliser les alternatives proposées dans la section suivante. De plus, le modèle de thread affecte les performances et l'environnement de sécurité des objets (voir « Informations avancées : problèmes de performances » dans cette rubrique).
Pour attribuer une portée d'application à un objet et la stocker dans l'objet intégré Application ASP, vous pouvez soit utiliser la balise <OBJECT> dans le fichier Global.asa, soit créer la portée de l'application à l'aide de la méthode Server.CreateObject sur l'instance d'objet de page ASP. .
Dans le fichier Global.asa, vous pouvez utiliser la balise ;OBJECT> qui étend l'attribut RUNAT (doit être défini sur Sever) et l'attribut SCOPE (doit être défini sur Session). Dans les pages ASP, vous pouvez utiliser Server.CreateObject pour stocker des instances d'objet dans l'objet intégré Application. Pour un exemple utilisant la balise <OBJECT> et Server.CreateObject, consultez la section précédente, « Donner une portée de session à un objet ».
Alternatives à la portée de session et d'application Donnez une portée de session ou d'application d'objet uniquement lorsque cela est nécessaire. Parce que ces objets restent jusqu'à la fin de la session ou de l'application. Ils consomment des ressources telles que de la mémoire ou des connexions à des bases de données qui pourraient être plus utiles par d'autres moyens. De plus, le modèle de thread d'un composant affecte les performances des objets que vous créez à partir de celui-ci, en particulier ceux qui ont une portée de session ou d'application.
Dans de nombreux cas, une meilleure approche que la création d'objets au niveau de l'application ou de la session consiste à utiliser des variables au niveau de la session ou de l'application pour transmettre des informations aux objets créés au niveau de la page. Par exemple, n'accordez pas la portée de la session ou de l'application à l'objet Connexion ADO, car la connexion qu'il crée restera ouverte pendant une longue période pendant que le script n'utilise plus le partage de connexion ODBC. Cependant, vous pouvez stocker la chaîne de connexion ODBC dans l'objet intégré Session ou Application et obtenir la chaîne à partir de l'instance d'objet Connection créée sur la page Web. De cette façon, vous pouvez stocker les informations fréquemment utilisées dans un espace de noms de session ou d'application, mais créer des objets avec ces informations uniquement lorsque cela est nécessaire.
Objets JScript définis par l'utilisateur Vous pouvez créer vos propres objets JScript en définissant un constructeur qui crée et initialise les propriétés et les méthodes du nouvel objet. Lorsqu'un script appelle le constructeur à l'aide de l'opérateur new, une instance de l'objet est créée. Le script ASP prend en charge les objets définis par l'utilisateur, qui fonctionnent correctement lorsqu'ils ont une portée de page. Toutefois, si un objet JScript défini par l'utilisateur se voit attribuer une portée d'application ou de session, cela peut affecter la fonctionnalité de l'objet. En particulier, si un objet a une portée de session ou d'application, les scripts d'autres pages peuvent obtenir les propriétés de l'objet mais ne peuvent pas appeler ses méthodes.
Informations avancées : problèmes de performances Le modèle de thread du composant peut affecter les performances du site Web. De manière générale, il est recommandé d'utiliser les objets marqués des deux dans tous les scripts ASP, en particulier dans les objets Session et Application. Les objets monothread sont obsolètes.
Étant donné que vous ne contrôlez pas toujours le modèle de thread des objets que vous utilisez, les instructions suivantes peuvent vous aider à obtenir des performances optimales :
Objet de portée de page. Les objets marqués Les deux ou Appartement vous offriront les meilleures performances.
Objet de portée d’application. En général, vous devez éviter de placer des objets dans l'objet Application. Si vous devez utiliser des objets de portée application, vous obtiendrez les meilleures performances d'un objet balisé à la fois combiné avec FreeThreadedMarshaler. Vous pouvez soit utiliser la balise <OBJECT>, soit utiliser la méthode Server.CreateObject pour stocker des objets avec les balises Single, Free ou Both dans l'objet Application. Vous devez utiliser la balise <OBJECT> avec des objets à thread cloisonné.
Objet de portée de session. Les objets marqués des deux vous offriront les meilleures performances. L'utilisation d'objets à thread unique ou à thread cloisonné entraînera le serveur Web à verrouiller la session sur un thread. Les objets à thread libre ne verrouillent pas la session, mais ne s'exécutent pas aussi rapidement. Dans l'objet Session, vous pouvez utiliser la balise <OBJECT> ou la méthode Server.CreateObject pour stocker des objets.
Si vous avez installé la documentation du SDK, vous obtiendrez des informations détaillées sur le modèle de thread et les performances des composants qu'il implique. (La documentation du SDK n'est pas disponible sous Windows 95 et versions ultérieures.)
