Qualquer pessoa que tenha escrito um ASP um pouco maior sabe que a sessão é realmente útil. Mas você realmente sabe como funciona a sessão? Talvez depois de entender, você nunca ousará usar esse objeto de ódio ao ódio. Embora o método de mudar para alternativas seja um pouco problemático, após considerações de longo prazo, tenho que fazê-lo.
Primeiro, vamos falar sobre os benefícios da sessão, que podem ser usados para registrar variáveis de dados de propriedade privada do cliente e não desaparecerão dentro do intervalo de tempo. Esta é realmente uma função importante, especialmente aqueles que devem ser usados por sistemas com membros. Por exemplo, a conta de login, o tempo, o status e muitos dados em tempo real do membro (como o sistema comercial registra os produtos na cesta de compras do usuário), essas informações são as necessidades privadas de cada usuário e, geralmente, o desenvolvedor usa IT.
No entanto, a sessão no ASP é composta por cookies e o servidor transmite todas as informações registradas na sessão para o navegador do usuário na forma de cookies. Geralmente, os navegadores salvam esses cookies. Este é o princípio operacional da sessão. Reconfigure a memória, etc. Ação inicial. Agora você pode pensar: "Eu tenho que usar essa função, então tenho que sacrificar um pouco". É claro que existem alternativas.
O aplicativo também é bom em gravar e processamento de dados temporários. O aplicativo não é como a sessão, que não passa os dados para o usuário e aguarda a próxima vez para ler on -line.
Como os objetos do aplicativo são públicos, a primeira coisa que deve ser feita é planejar uma área comum para cada usuário, para que cada usuário tenha sua própria área para registrar dados para obter o objetivo de uma sessão de simulação. Existem duas maneiras de fazer isso agora:
1. Inicialize e alocem o espaço de memória do usuário com antecedência quando o servidor é ativado. . No entanto, há uma limitação. Pequenos programas, como salas de bate -papo.
2. Esse método deve ser considerado mais apropriado para aplicativos grandes. O objetivo dessas duas soluções de sessão simulado é reduzir o consumo de recursos de sessão, mas, afinal, ainda é insubstituível.
■ Primeiro plano
Primeiro, iniciamos a implementação da primeira solução.
A inicialização foi concluída, mas como usá -lo? Só precisamos alterar as informações armazenadas na sessão, como conta e tempo de login, no objeto de aplicativo que criamos, onde o usuário faz login:
| 'Procurando por um espaço não utilizado Para i = 1 para aplicação (clientmax) Se aplicação (user_status_ & i) = 0 então 'Número temporário do usuário Sessão (índice) = i 'bloqueio Aplicativo Application.lock 'Definido para o estado usado Aplicativo (user_status_ & i) = 1 'colocado em dados variáveis Aplicativo (user_account_ & i) = conta Aplicativo (user_logtime_ & i) = agora () 'Desbloqueado Application.unlock Saída para Final se Próximo |
Para obter os dados variáveis relevantes do usuário, é como o seguinte:
| Response.Write (Application (User_Account_ & Session (Index)) |
Você pode achar que não quer dizer não usar sessão? Então, por que a sessão existe no código original acima? Como mencionado anteriormente, essa alternativa não pode substituir completamente a sessão. Nesse momento, temos que confiar na sessão. . Este método tem algumas melhorias, mas é suficiente para pequenas aplicações.
■ Segundo plano
Em relação à solução anterior, você também pode pensar que nosso número personalizado usa sessão para gravar. É isso mesmo, não importa se querermos usá -lo ou não, o servidor ajudará automaticamente cada usuário a atribuir um número e esse número não será repetido. Essa numeração é uma ação que a sessão definitivamente será executada, para que possamos usá -la para substituir o programa de numeração que nos escrevemos, o que economiza outro esforço e até tem maior expansão. Mas, basicamente, a primeira solução acima ainda é útil, como salas de bate -papo que limitam o número de pessoas e outras pequenas aplicações.
Se um site com centenas, milhares ou até dezenas de milhares de pessoas em um site a cada segundo, definitivamente não funcionará se usar a solução anterior. Suponha que você defina o limite superior de 10.000 pessoas, uma vez que o servidor seja ativado, ele ajudará você a cortar 10.000 áreas para se preparar para 10.000 usuários. Ele é responsável por mais de 320.000 K (320 MB). Poucos, acho que 512 MB são suficientes. Portanto, a solução é configurar dinamicamente o espaço variável do usuário e cortar uma área quando um usuário estiver online com o servidor; portanto, não há necessidade de configurar uma memória enorme com antecedência.
A segunda solução é relativamente simples de fazer.
| 'Lock ApplicationApplication.lock' coloque dados variáveis Aplicativo (user_account_ & session.sessionId) = conta Aplicativo (user_logtime_ & session.sessionId) = agora () 'desbloqueio desbloquear aplicativo.unlock |
Para obter os dados variáveis relevantes do usuário, é como o seguinte:
| Response.Write (Application (user_account_ & session.sessionId)) |
No passado, li muitos livros que diziam que era muito difícil comer recursos, então tente não usá -los, mas ainda tenho que usá -los quando precisar, e os livros não ensinaram uma solução mais apropriada. Agora, quando você entender como substituir a sessão, faça bom uso! Talvez os problemas de eficiência que estão sempre perturbados possam ser muito aprimorados!