Pergunta

Estou analisando o código do meu antecessor e vejo o uso do escopo "solicitação" com frequência.Qual é o uso apropriado deste escopo?

Foi útil?

Solução

Existem vários escopos disponíveis para qualquer parte do seu código:Sessão, Cliente, Cookie, Aplicativo e Solicitação.Alguns são desaconselháveis ​​para uso de certas maneiras (ou seja,usando o escopo Request ou Application dentro de suas Custom Tags ou CFC's;isso é acoplamento, viola os princípios de encapsulamento e é considerada uma má prática) e alguns têm propósitos especiais:O cookie é mantido na máquina do cliente como cookies físicos, e as variáveis ​​com escopo de sessão são específicas do usuário e expiram com a sessão do usuário no site.

Se é extremamente improvável que uma variável mude (constante para todos os efeitos) e pode simplesmente ser inicializada na inicialização do aplicativo e nunca mais escrita, geralmente você deve colocá-la no escopo do Aplicativo porque isso persiste entre cada usuário e cada sessão.Quando implementado corretamente, ele é escrito uma vez e lido N vezes.

Uma implementação adequada de variáveis ​​de aplicativo em Application.cfm pode ser assim:

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

Observe que a existência da variável no escopo da aplicação é verificada antes e depois do bloqueio, de forma que se dois usuários criarem uma race Condition na inicialização da aplicação, apenas um deles acabará configurando as variáveis ​​da aplicação.

A vantagem dessa abordagem é que ela não atualizará constantemente essas variáveis ​​armazenadas em cada solicitação, desperdiçando o tempo do usuário e os ciclos de processamento do servidor.A desvantagem é que é um pouco detalhado e complexo.

Isso foi bastante simplificado com a adição de Application.cfc.Agora, você pode especificar quais variáveis ​​são criadas na inicialização do aplicativo e não precisa se preocupar em bloquear e verificar a existência e todas essas coisas 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 obter mais informações sobre Application.cfc, incluindo todas as diversas funções especiais disponíveis e todos os pequenos detalhes sobre o que e como usá-lo, Eu recomendo esta postagem no blog de Raymond Camden.

Para resumir, o escopo da solicitação está disponível em todos os lugares do seu código, mas isso não significa necessariamente que seja "certo" usá-lo em todos os lugares.Provavelmente, seu antecessor o estava usando para quebrar o encapsulamento e isso pode ser complicado de refatorar.Talvez seja melhor deixá-lo como está, mas entender qual escopo é a melhor ferramenta para o trabalho certamente tornará seu código futuro melhor.

Outras dicas

Esta é uma questão muito subjetiva, e alguns até argumentariam que nunca é “apropriado” usar o escopo de solicitação em aplicativos ColdFusion modernos.

Com essa isenção de responsabilidade resolvida, vamos definir qual é o escopo da solicitação e onde ele seria útil.

O escopo da solicitação é o escopo global absoluto em uma única solicitação de página do ColdFusion.Não é um escopo compartilhado, como escopos de aplicativo, servidor, cliente e sessão, portanto, o bloqueio não é necessário para torná-lo seguro para threads (a menos que você gere threads de trabalho a partir de uma única solicitação usando a tag CFTHREAD do CF8).Como escopo global, é uma maneira muito conveniente de persistir variáveis ​​em qualquer nível da pilha da solicitação sem precisar passá-las do pai para o chamador.Essa era uma maneira muito comum de persistir variáveis ​​por meio de tags personalizadas aninhadas ou recursivas em aplicativos CF mais antigos.

Observe que, embora muitos aplicativos usem esse escopo para armazenar variáveis ​​no nível do aplicativo (definições de configuração, por exemplo), a grande (e às vezes sutil) diferença entre o escopo da solicitação e o escopo do aplicativo é que o valor da mesma variável com escopo de solicitação pode diferem entre solicitações de páginas individuais.

Eu acho que seu antecessor usou esse escopo como um meio de definir convenientemente variáveis ​​​​que precisavam sobreviver ao salto entre unidades de código encapsuladas ou aninhadas, sem ter que passá-las explicitamente.

Ok, eu só queria comentar seu código.Por favor, me perdoe se pareço louco.Mas você já verificou que o structKeyExists no começo.Como você sabe que isso será verdade, não faria sentido fazer outra verificação.Então minha versão seria essa...Mas isso sou só eu.


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

Tudo bem.

Estou escrevendo a estrutura da minha empresa que será usada para impulsionar nosso site.

Eu uso a variável request para definir determinados dados que estariam disponíveis para os outros CFC's. Tive que fazer isso para que os dados ficassem disponíveis em toda a aplicação, sem a necessidade de passar continuamente os dados.Sinceramente, acredito que usando request e application desde que seja um componente de função estática, você não deverá ter problemas.Não tenho certeza se estou errado em meu pensamento sobre isso, mas assim que eu lançar a estrutura, veremos.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top