ColdFusion: ¿cuándo usar el alcance de "solicitud"?

railo cfml

Question

Revisé el código de mi predecesor y veo el uso del alcance de "solicitud" con frecuencia. ¿Cuál es el uso apropiado de este alcance?

Answer 1

Hay varios ámbitos disponibles para cualquier parte de su código: sesión, cliente, cookie, aplicación y solicitud. Algunos son desaconsejables para usar de ciertas maneras (es decir, usar el alcance Solicitud o Aplicación dentro de sus Etiquetas personalizadas o CFC, esto es acoplamiento , viola los principios de encapsulación y se considera una mala práctica) y algunos tienen propósitos especiales: Cookie persiste en el cliente máquina como cookies físicas y las variables de ámbito de la sesión son específicas del usuario y caducan con la sesión del usuario en el sitio web.

Si es muy poco probable que una variable cambie (constante para todos los efectos) y puede inicializarse simplemente al inicio de la aplicación y nunca volver a escribirse, generalmente debe ponerlo en el ámbito de la Aplicación porque esto persiste entre cada usuario y cada sesión. Cuando se implementa correctamente, se escribe una vez y se lee N veces.

Una implementación adecuada de las variables de aplicación en Application.cfm podría verse así:

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

Tenga en cuenta que la existencia de la variable en el ámbito de la aplicación se verifica antes y después del bloqueo, de modo que si dos usuarios crean una condición de carrera al inicio de la aplicación, solo uno de ellos terminará configurando las variables de la aplicación.

El beneficio de este enfoque es que no actualizará constantemente estas variables almacenadas en cada solicitud, desperdiciando el tiempo del usuario y los ciclos de procesamiento del servidor. El trade-off es que es un poco detallado y complejo.

Esto se simplificó enormemente con la adición de Application.cfc. Ahora, puede especificar qué variables se crean en el inicio de la aplicación y no tiene que preocuparse por bloquear y verificar la existencia y todas esas cosas divertidas:

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

Para obtener más información sobre Application.cfc, incluidas todas las funciones especiales disponibles y cada pequeño detalle sobre qué y cómo usarlo, recomiendo esta publicación en el blog de Raymond Camden .

En resumen, el alcance de la solicitud está disponible en todas partes en su código, pero eso no necesariamente lo hace "correcto" para usarlo en todas partes. Lo más probable es que su predecesor lo haya utilizado para romper la encapsulación, y eso puede ser engorroso para refactorizar. Puede ser mejor dejarlo tal como está, pero comprender qué alcance es la mejor herramienta para el trabajo definitivamente mejorará su futuro código.

Answer 2

Esta es una pregunta muy subjetiva, e incluso algunos argumentarían que nunca es "apropiado" utilizar el alcance de la solicitud en las aplicaciones modernas de ColdFusion.

Con ese descargo de responsabilidad fuera del camino, definamos cuál es el alcance de la solicitud y dónde sería útil.

El alcance de la solicitud es el alcance global absoluto en una única solicitud de página de ColdFusion. No es un ámbito compartido, como aplicación, servidor, cliente y ámbitos de sesión, por lo que no es necesario bloquearlo para que sea seguro (a menos que genere subprocesos de trabajo a partir de una sola solicitud utilizando la etiqueta CFTHREAD de CF8). Como ámbito global, es una forma muy conveniente de persistir variables a través de cualquier nivel en la pila de solicitudes sin tener que pasarlas de padres a llamantes. Esta era una forma muy común de persistir variables a través de etiquetas personalizadas anidadas o recursivas en aplicaciones CF anteriores.

Tenga en cuenta que aunque muchas aplicaciones usan este ámbito para almacenar variables de nivel de aplicación (configuración de configuración, por ejemplo), la gran diferencia (y en ocasiones sutil) entre el alcance de la solicitud y el alcance de la aplicación es que el valor de la misma variable con ámbito de solicitud puede difieren entre las solicitudes de página individuales.

Supongo que su predecesor usó este alcance como un medio para establecer convenientemente las variables que necesitaban para sobrevivir al salto entre unidades de código encapsuladas o anidadas sin tener que pasarlas de forma explícita.

Answer 3

De acuerdo, solo quería comentar tu código. Por favor perdóname si parezco loco. Pero ya has verificado que structKeyExists al principio. Como sabes que va a ser cierto, no tendría sentido ejecutar otro control. Entonces mi versión de esto sería esta ... Pero así soy yo.

<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

He estado escribiendo el marco de trabajo de mi empresa que se usará para impulsar nuestro sitio.

Utilizo la variable de solicitud para establecer ciertos datos que estarían disponibles para los demás CFC. Tenía que hacer esto para que los datos estuvieran disponibles en toda la aplicación, sin la necesidad de pasar continuamente los datos. Sinceramente, creo que el uso de solicitud y la aplicación, siempre y cuando es un componente de función estática, entonces no debería tener un problema. No estoy seguro de si estoy equivocado en mi forma de pensar con esto, pero una vez que lance el marco veremos.