ColdFusion - Quand utiliser le scope « request » ?

Question

J'ai parcouru le code de mon prédécesseur et j'ai fréquemment constaté l'utilisation de la portée "requête".Quelle est l’utilisation appropriée de cette portée ?

Answer 1

Plusieurs étendues sont disponibles pour n'importe quelle partie de votre code :Session, Client, Cookie, Application et Demande.Certains sont déconseillés d'utiliser de certaines manières (c.-à-d.en utilisant la portée de la demande ou de l'application dans vos balises personnalisées ou vos CFC ;c'est couplage, viole les principes d'encapsulation et est considéré comme une mauvaise pratique), et certains ont des objectifs particuliers :Le cookie est conservé sur la machine client en tant que cookies physiques, et les variables de session sont spécifiques à l'utilisateur et expirent avec la session de l'utilisateur sur le site Web.

S'il est extrêmement peu probable qu'une variable change (constante à toutes fins utiles) et peut simplement être initialisée au démarrage de l'application et ne jamais être réécrite, vous devez généralement la placer dans la portée de l'application car cela la conserve entre chaque utilisateur et chaque session.Lorsqu'il est correctement implémenté, il est écrit une fois et lu N fois.

Une implémentation correcte des variables d'application dans Application.cfm pourrait ressembler à ceci :

<cfif not structKeyExists(application, "dsn")>
    <cflock scope="application" type="exclusive" timeout="30">
        <cfif not structKeyExists(application, "dsn")>
            <cfset application.dsn = "MyDSN" />
            <cfset foo = "bar" />
            <cfset x = 5 />
        </cfif>
    </cflock>
</cfif>

Notez que l'existence de la variable dans le périmètre de l'application est vérifiée avant et après le verrouillage, de sorte que si deux utilisateurs créent une condition de concurrence critique au démarrage de l'application, un seul d'entre eux finira par définir les variables de l'application.

L'avantage de cette approche est qu'elle n'actualisera pas constamment ces variables stockées à chaque requête, ce qui fera perdre du temps à l'utilisateur et aux cycles de traitement du serveur.Le compromis est que c'est un peu verbeux et complexe.

Cela a été grandement simplifié avec l'ajout de Application.cfc.Désormais, vous pouvez spécifier quelles variables sont créées au démarrage de l'application et vous n'avez plus à vous soucier du verrouillage et de la vérification de l'existence et de toutes ces choses amusantes :

<cfcomponent>
    <cfset this.name = "myApplicationName" />

    <cffunction name="onApplicationStart" returnType="boolean" output="false">
        <cfset application.dsn = "MyDSN" />
        <cfset foo = "bar" />
        <cfset x = 5 />
        <cfreturn true />
    </cffunction>
</cfcomponent>

Pour plus d'informations sur Application.cfc, y compris toutes les différentes fonctions spéciales disponibles et tous les petits détails sur quoi et comment l'utiliser, Je recommande cet article sur le blog de Raymond Camden.

Pour résumer, la portée de la requête est disponible partout dans votre code, mais cela ne signifie pas nécessairement qu'il est « correct » de l'utiliser partout.Il y a de fortes chances que votre prédécesseur l'utilisait pour rompre l'encapsulation, et cela peut être difficile à refactoriser.Il serait peut-être préférable de le laisser tel quel, mais comprendre quelle portée est le meilleur outil pour le travail améliorera certainement votre futur code.

Answer 2

C'est une question très subjective, et certains diraient même qu'il n'est jamais « approprié » d'utiliser la portée de la requête dans les applications ColdFusion modernes.

Cette clause de non-responsabilité étant réglée, définissons quelle est la portée de la demande et où elle serait utile.

La portée de la requête est la portée globale absolue dans une seule requête de page ColdFusion.Il ne s'agit pas d'une portée partagée, comme les portées d'application, de serveur, de client et de session, donc le verrouillage n'est pas nécessaire pour la rendre thread-safe (sauf si vous générez des threads de travail à partir d'une seule requête à l'aide de la balise CFTHREAD de CF8).En tant que portée globale, il s'agit d'un moyen très pratique de conserver des variables à n'importe quel niveau de la pile de la requête sans avoir à les transmettre du parent à l'appelant.Il s'agissait d'un moyen très courant de conserver des variables via des balises personnalisées imbriquées ou récursives dans les anciennes applications CF.

Notez que même si de nombreuses applications utilisent cette portée pour stocker des variables au niveau de l'application (paramètres de configuration, par exemple), la grande (et parfois subtile) différence entre la portée de la demande et la portée de l'application est que la valeur de la même variable de portée de la demande peut diffèrent selon les demandes de pages individuelles.

Je suppose que votre prédécesseur a utilisé cette portée comme moyen de définir facilement les variables qui devaient survivre au saut entre les unités de code encapsulées ou imbriquées sans avoir à les transmettre explicitement.

Answer 3

D'accord, je voulais juste commenter votre code.S'il vous plaît, pardonnez-moi si j'ai l'air fou.Mais vous avez déjà vérifié que le structKeyExists au début.Puisque vous savez que cela va être vrai, cela n’aurait aucun sens de procéder à une autre vérification.Donc ma version serait la suivante...Mais c'est juste moi.

---

<cfif not structKeyExists(application, "dsn")>
    <cflock scope="application" type="exclusive" timeout="30">
            <cfset application.dsn = "MyDSN" />
            <cfset foo = "bar" />
            <cfset x = 5 />
    </cflock>
</cfif>

---

Bien.

Answer 4

J'ai écrit le framework de mon entreprise qui sera utilisé pour alimenter notre site.

J'utilise la variable de requête pour définir certaines données qui seraient disponibles pour les autres CFC. Je devais le faire afin que les données soient disponibles dans toute l'application, sans avoir besoin de transmettre continuellement les données.Je crois honnêtement qu'en utilisant request et application tant qu'il s'agit d'un composant de fonction statique, vous ne devriez pas avoir de problème.Je ne sais pas si je me trompe dans ma réflexion, mais une fois que j'aurai publié le cadre, nous verrons.