ColdFusion - Quando utilizzare l'ambito "richiesta"?

Question

Ho esaminato il codice del mio predecessore e ho visto frequentemente l'utilizzo dell'ambito "richiesta".Qual è l'uso appropriato di questo ambito?

Answer 1

Sono disponibili diversi ambiti per qualsiasi parte del codice:Sessione, Cliente, Cookie, Applicazione e Richiesta.Alcuni sono sconsigliabili da utilizzare in determinati modi (ad es.utilizzando l'ambito della richiesta o dell'applicazione all'interno dei tag personalizzati o dei CFC;questo è accoppiamento, viola i principi di incapsulamento ed è considerata una cattiva pratica) e alcuni hanno scopi speciali:Il cookie viene mantenuto sul computer client come cookie fisici e le variabili con ambito Session sono specifiche dell'utente e scadono con la sessione dell'utente sul sito Web.

Se è estremamente improbabile che una variabile cambi (costante a tutti gli effetti) e può essere semplicemente inizializzata all'avvio dell'applicazione e mai più scritta, in genere è necessario inserirla nell'ambito dell'applicazione perché ciò la persiste tra ogni utente e ogni sessione.Se implementato correttamente viene scritto una volta e letto N volte.

Una corretta implementazione delle variabili dell'applicazione in Application.cfm potrebbe assomigliare a questa:

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

Si noti che l'esistenza della variabile nell'ambito dell'applicazione viene verificata prima e dopo il blocco, in modo che se due utenti creano una race condition all'avvio dell'applicazione, solo uno di loro finirà per impostare le variabili dell'applicazione.

Il vantaggio di questo approccio è che non aggiornerà costantemente queste variabili memorizzate a ogni richiesta, facendo sprecare tempo all'utente e cicli di elaborazione del server.Il compromesso è che è un po’ prolisso e complesso.

Ciò è stato notevolmente semplificato con l'aggiunta di Application.cfc.Ora puoi specificare quali variabili vengono create all'avvio dell'applicazione e non devi preoccuparti di bloccarle, verificarne l'esistenza e tutte quelle cose divertenti:

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

Per maggiori informazioni su Application.cfc comprese tutte le varie funzioni speciali disponibili e ogni piccolo dettaglio su cosa e come usarlo, Raccomando questo post sul blog di Raymond Camden.

Per riassumere, l'ambito della richiesta è disponibile ovunque nel codice, ma ciò non rende necessariamente "giusto" utilizzarlo ovunque.È probabile che il tuo predecessore lo stesse utilizzando per interrompere l'incapsulamento e che il refactoring possa essere complicato.Potrebbe essere meglio lasciarlo così com'è, ma capire quale ambito è lo strumento migliore per il lavoro renderà sicuramente migliore il tuo codice futuro.

Answer 2

Questa è una domanda molto soggettiva e alcuni sostengono addirittura che non è mai "appropriato" utilizzare l'ambito della richiesta nelle moderne applicazioni ColdFusion.

Tolta questa clausola di esclusione della responsabilità, definiamo qual è l'ambito della richiesta e dove sarebbe utile.

L'ambito della richiesta è l'ambito globale assoluto in una singola richiesta di pagina ColdFusion.Non è un ambito condiviso, come gli ambiti applicazione, server, client e sessione, quindi il blocco non è necessario per renderlo sicuro per i thread (a meno che non si generino thread di lavoro da una singola richiesta utilizzando il tag CFTHREAD di CF8).Essendo un ambito globale, è un modo molto conveniente per rendere persistenti le variabili attraverso qualsiasi livello nello stack della richiesta senza doverle passare dal genitore al chiamante.Questo era un modo molto comune per rendere persistenti le variabili tramite tag personalizzati nidificati o ricorsivi nelle vecchie app CF.

Tieni presente che mentre molte applicazioni utilizzano questo ambito per archiviare variabili a livello di applicazione (impostazioni di configurazione, ad esempio), la grande (e talvolta sottile) differenza tra l'ambito della richiesta e l'ambito dell'applicazione è che il valore della stessa variabile con ambito della richiesta può differiscono tra le singole richieste di pagina.

Immagino che il tuo predecessore abbia utilizzato questo ambito come mezzo per impostare comodamente le variabili necessarie per sopravvivere al salto tra unità di codice incapsulate o nidificate senza doverle passare esplicitamente.

Answer 3

Ok, volevo solo commentare il tuo codice.Per favore perdonami se sembro pazzo.Ma hai già verificato che structKeyExists all'inizio.Dato che sai che sarà vero, non avrebbe senso eseguire un altro controllo.Quindi la mia versione sarebbe questa...Ma sono solo io.

---

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

---

Bene.

Answer 4

Ho scritto il framework della mia azienda che verrà utilizzato per alimentare il nostro sito.

Utilizzo la variabile di richiesta per impostare determinati dati che sarebbero disponibili per gli altri CFC. Dovevo farlo in modo che i dati fossero disponibili in tutta l'applicazione, senza la necessità di passare continuamente i dati.Onestamente credo che utilizzando request e application fintanto che è un componente di funzione statica non dovresti avere problemi.Non sono sicuro di sbagliarmi nel pensare a questo, ma una volta rilasciato il framework vedremo.