Explicação detalhada do Web.config + otimização do asp.net
Autor：Eve Cole
Data da Última Atualização：2009-07-01 16:44:14
1. Compreendendo o arquivo Web.config
O arquivo Web.config é um arquivo de texto xml, usado para armazenar as informações de configuração do aplicativo Web asp.NET (como o método de autenticação mais comumente usado para configurar o aplicativo Web asp.NET). etapa do aplicativo no diretório. Quando você cria um novo aplicativo Web por meio do .NET, um arquivo Web.config padrão é criado automaticamente no diretório raiz por padrão, incluindo definições de configuração padrão, e todos os subdiretórios herdam suas definições de configuração. Se desejar modificar as definições de configuração de um subdiretório, você poderá criar um novo arquivo Web.config no subdiretório. Ele pode fornecer informações de configuração além das informações de configuração herdadas do diretório pai e também pode substituir ou modificar configurações definidas no diretório pai.
(1).Web.Config é armazenado na especificação do arquivo xml e o arquivo de configuração é dividido nos seguintes formatos
1. Características da declaração do manipulador da seção de configuração: localizada na parte superior do arquivo de configuração e contida na tag <configSections>.
2. Recursos específicos de configuração do aplicativo: Localizados em <appSetting>. Você pode definir informações como configurações de constantes globais para o aplicativo.
3. Recursos de configuração da seção de configuração: Localizado na seção <system.Web>, ele controla o comportamento do tempo de execução do asp.net.
4. Recursos de grupos de seções de configuração: Usando a tag <sectionGroup>, você pode personalizar o agrupamento e colocá-lo dentro de <configSections> ou dentro de outras tags <sectionGroup>.
(2). Cada seção da seção de configuração.
1.<configuração> elemento raiz da seção, outras seções estão dentro dele.
2. Seção <appSetting> Esta seção é usada para definir as configurações do aplicativo. Para algumas configurações incertas, os usuários também podem definir seu próprio uso de acordo com a situação real:
I.<appSettings>
<add key="Conntction" value="server=192.168.85.66;userid=sa;password=;database=Info;"/>
<configurações do aplicativo>
Uma constante de cadeia de conexão é definida e a cadeia de conexão pode ser modificada em aplicativos reais sem modificar o código do programa.
II.<configurações do aplicativo>
<add key="ErrPage" value="Error.aspx"/><appSettings> define uma página de redirecionamento de erro.
3. Formato da seção <compilação>:
<compilação
idioma padrão = "c #"
depuração = "verdadeiro"
/>
I. idioma padrão: Defina o idioma do código de fundo, você pode escolher dois idiomas: c# e vb.net.
IIdebug: Quando verdadeiro, a depuração aspx é iniciada; quando falso, a depuração aspx não é iniciada, melhorando assim o desempenho da aplicação quando ela está em execução. Geralmente, os programadores definem-no como verdadeiro ao desenvolver e como falso ao entregá-lo aos clientes.
4. Formato da seção <customErrors>:
<customErrors
mode = "Somente remoto"
padrãoRedirect = "erro.aspx"
<error statusCode="440" redirecionamento="err440page.aspx"/>
<error statusCode="500" redirecionamento="err500Page.aspx"/>
/>
I.mode: Possui 3 estados: On, Off e RemoteOnly. On significa que as informações personalizadas são sempre exibidas; Off significa que as informações detalhadas de erro do asp.net são sempre exibidas. RemoteOnly significa que as informações personalizadas são exibidas apenas para usuários que não estão executando no servidor web local;
II.defaultRedirect: endereço URL usado para redirecionar quando ocorre um erro Opcional.
III.statusCode: Indica o código de status do erro, indicando um status de erro específico.
IV. redirecionamento: URL redirecionado com erro.
5. Formato da seção <globalização>:
<globalização
requestEncoding="utf-8"
respostaEncoding="utf-8"
fileEncoding="utf-8"
/>
I.requestEncoding: É usado para verificar a codificação de cada solicitação recebida.
II.responseEncoding: utilizado para verificar a codificação do conteúdo da resposta enviada de volta.
III.fileEncoding: usado para verificar a codificação padrão para aspx, asax e outras análises de arquivos.
6. Formato da seção <sessionState>:
<sessãoEstado
modo = "InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString = "fonte de dados = 127.0.0.1; Trusted_Connection = sim"
sem cookies = "falso"
tempo limite = "20"
/>
I.mode: dividido em estados off, Inproc, StateServer, SqlServer
mode = InProc é armazenado no processo Recursos: tem o melhor desempenho e velocidade mais rápida, mas não pode ser compartilhado entre vários servidores mode = "StateServer" é armazenado no servidor de estado. servidores, use este método. No entanto, as informações são armazenadas no servidor de estado. Quando o servidor de estado falhar, as informações serão perdidas. Modo = "SqlServer" é armazenado no servidor sql.
II. stateConnectionString: Especifique o nome do servidor onde o aplicativo asp.net armazena o estado da sessão remota. O padrão é a máquina local.
III.sqlConnectionString: Ao usar um banco de dados de estado de sessão, defina a string de conexão aqui
IV. Cookieless: Quando definido como verdadeiro, significa que o estado da sessão do cookie não é utilizado para identificar o cliente, caso contrário, o oposto é verdadeiro;
V. TimeOut: Utilizado para definir o tempo de armazenamento do estado da sessão. Caso o limite de tempo seja ultrapassado, a sessão será encerrada automaticamente.
7. Formato da seção <autenticação>:
<modo de autenticação="Formulários">
<forms name=".ASPXUSERDEMO" loginUrl="Login.aspx" proteção="Todos" timeout="30"/>
</autenticação>
<autorização>
<negar usuários="?"/>
</autorização>
I.Windows: Use o método de autenticação IIS
II.Formulários: Usando validação baseada em formulários
III.Passport: Use o modo de verificação de cookies do Passport
IV.Nenhum: não utiliza nenhum método de verificação O significado dos atributos do nó Formulários nele incorporados:
I.Name: Especifica o nome do cookie HTTP usado para completar a autenticação.
II.LoginUrl: O URL da página que é redirecionado se a verificação falhar ou expirar, geralmente a página de login, permitindo que o usuário faça login novamente.
III.Proteção: Especifique o método de proteção dos dados dos cookies.
Pode ser definido como: Todos Nenhum Validação de criptografia Quatro métodos de proteção
a. Todos significa criptografar dados e realizar verificação de validade de duas maneiras.
b. Nenhum significa que os cookies não estão protegidos.
c. Criptografia significa criptografar o conteúdo do cookie.
d. Validação significa verificar a validade do conteúdo do Cookie.
IV. TimeOut: Especifique o tempo de expiração do cookie.
As modificações no arquivo Web.config em tempo de execução podem entrar em vigor sem reiniciar o serviço (Nota: exceção para a seção <processModel>). É claro que o arquivo Web.config é extensível. Você pode personalizar novos parâmetros de configuração e escrever manipuladores de seção de configuração para lidar com eles.
O arquivo de configuração web.config (configurações padrão), todo o código a seguir deve estar localizado em
<configuração>
<sistema.web>
e
</system.web>
</configuração>
Para fins de aprendizagem, os exemplos a seguir omitem esta tag xml.
1. A função da seção <autenticação>: configurar o suporte à autenticação asp.NET (quatro tipos: Windows, Forms, PassPort e Nenhum). Este elemento só pode ser declarado no nível do computador, site ou aplicativo. O elemento <authentication> deve ser usado com a seção <authorization>.
Exemplo:
O exemplo a seguir é um site de configuração de autenticação baseado em formulário. Quando um usuário que não está conectado acessa uma página da Web que requer autenticação, a página da Web salta automaticamente para a página de login.
<modo de autenticação="Formulários" >
<formulários loginUrl="logon.aspx" name=".FormsAuthCookie"/>
</autenticação>
O elemento loginUrl representa o nome da página de login e name representa o nome do cookie.
2. A função da seção <authorization>: controla o acesso do cliente aos recursos de URL (como permitir o acesso de usuários anônimos). Este elemento pode ser declarado em qualquer nível (computador, site, aplicativo, subdiretório ou página). Obrigatório em conjunto com a seção <authentication>.
Exemplo: o exemplo a seguir desativa o acesso a usuários anônimos
<autorização>
<negar usuários="?"/>
</autorização>
Nota: Você pode usar user.identity.name para obter o nome de usuário autenticado atual; você pode usar o método web.Security.FormsAuthentication.RedirectFromLoginPage para redirecionar o usuário autenticado para a página específica que o usuário acabou de solicitar.
3. A função da seção <compilação>: definir todas as configurações de compilação usadas pelo asp.NET. O atributo de depuração padrão é "True". Ele deve ser definido como False após o programa ser compilado e entregue para uso (os detalhes estão descritos no arquivo Web.config e o exemplo é omitido aqui)
4.<Errospersonalizados>
Função: Fornece informações sobre mensagens de erro personalizadas para aplicativos asp.NET. Não se aplica a erros que ocorrem em serviços da web XML.
Exemplo: quando ocorrer um erro, vá para uma página de erro personalizada.
<customErrors defaultRedirect="ErrorPage.aspx" mode="RemoteOnly">
</customErrors>
O elemento defaultRedirect representa o nome da página da web de erro personalizada. O elemento mode indica: exibir informações personalizadas (amigáveis) para usuários que não estão executando no servidor Web local.
5. A função da seção <httpRuntime>: definir as configurações de tempo de execução HTTP do asp.NET. Esta seção pode ser declarada nos níveis de computador, site, aplicativo e subdiretório.
Exemplo: controle o tamanho máximo dos arquivos de upload do usuário para 4 milhões, o tempo máximo para 60 segundos e o número máximo de solicitações para 100
<httpRuntime maxRequestLength="4096" execuçãoTimeout="60" appRequestQueueLimit="100"/>
6. <páginas>
Função: identifica definições de configuração específicas da página (como ativar o estado da sessão, visualizar o estado, detectar a entrada do usuário, etc.). <pages> pode ser declarado nos níveis de computador, site, aplicativo e subdiretório.
Exemplo: Não detecte se há dados potencialmente perigosos no conteúdo inserido pelo usuário no navegador (Nota: Este item é detectado por padrão. Se você usar a não detecção, deverá codificar ou verificar a entrada do usuário a partir do). cliente O estado de visualização criptografado é verificado quando a página é postada novamente para verificar se o estado de visualização não foi adulterado no lado do cliente. (Nota: Este item não é verificado por padrão)
<pages buffer="true" enableViewStateMac="true" validRequest="false"/>
7. <sessãoEstado>
Função: Defina as configurações do estado da sessão para o aplicativo atual (como definir se o estado da sessão deve ser ativado e onde salvar o estado da sessão).
Exemplo:
<sessionState mode="InProc" cookieless="true" timeout="20"/>
</sessionState>
Observação:
mode="InProc" significa: armazenar o estado da sessão localmente (você também pode optar por armazená-lo em um servidor remoto ou servidor SAL ou desabilitar o estado da sessão)
cookieless="true" significa: ativar o estado da sessão se o navegador do usuário não suportar cookies (o padrão é False)
timeout="20" significa: o número de minutos que a sessão pode ficar inativa
8. <traço>
Função: Configure o serviço de rastreamento asp.NET, usado principalmente para testes de programas para determinar onde ocorrem erros.
Exemplo: a seguir está a configuração padrão em Web.config:
<trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />
Observação:
enabled="false" significa não ativar o rastreamento;
requestLimit="10" especifica o número de solicitações de rastreamento armazenadas no servidor
pageOutput="false" significa que a saída do rastreio só pode ser acessada por meio do utilitário de rastreio;
traceMode="SortByTime" indica que as informações de rastreamento são exibidas na ordem em que os rastreamentos são processados.
localOnly="true" significa que o visualizador de rastreamento (trace.axd) é usado apenas para o servidor Web host. O processo da seção de configuração do arquivo Web.config personalizado é dividido em duas etapas.
1. Declare o nome da seção de configuração e o nome da classe .NET Framework que manipula os dados de configuração na seção entre as tags <configSections> e </configSections> na parte superior do arquivo de configuração.
2. Faça as definições de configuração reais para a seção declarada após a área <configSections>.
Exemplo: Crie uma seção para armazenar strings de conexão de banco de dados
<configuração>
<seções de configuração>
<section name="appSettings" type="System.Configuration.NameValueFileSectionHandler, System, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
</configSections>
<configurações do aplicativo>
<add key="scon" value="server=a;database=northwind;uid=sa;pwd=123"/>
</appSettings>
<sistema.web>
...
</system.web>
</configuração>
Acessando o arquivo Web.config Você pode acessar o arquivo Web.config usando a coleção de cadeias de caracteres estáticas ConfigurationSettings.AppSettings Exemplo: Obtenha a cadeia de conexão estabelecida no exemplo acima. Por exemplo:
string estática protegida Isdebug = ConfigurationSettings.AppSettings["debug"]
2. Explicação detalhada da configuração da sessão em web.config Após abrir o arquivo de configuração Web.config de uma aplicação, encontraremos o seguinte parágrafo:
< estado da sessão
modo = "InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString = "fonte de dados = 127.0.0.1; Trusted_Connection = sim"
sem cookies = "falso"
tempo limite = "20"
/>
Esta seção configura como o aplicativo armazena informações de sessão. Nossas diversas operações abaixo estão focadas principalmente nesta configuração. Vamos primeiro dar uma olhada no significado do conteúdo contido nesta configuração. A sintaxe do nó sessionState é a seguinte:
< sessionState mode="Desligado|InProc|StateServer|SQLServer"
cookieless = "verdadeiro | falso"
timeout="número de minutos"
stateConnectionString="tcpip=servidor:porta"
sqlConnectionString="string de conexão sql"
stateNetworkTimeout="número de segundos"
/>
Os atributos obrigatórios são: atributo opção descrição
modo define onde armazenar informações da sessão
Ø Off está definido para não usar a função de sessão.
Ø InProc está configurado para armazenar a sessão no processo, que é o método de armazenamento em asp.
Ø StateServer está configurado para armazenar a sessão em um serviço de estado independente.
Ø As configurações do SQLServer armazenam a sessão no sql server.
Os atributos opcionais são: atributo opção descrição
Ø conjuntos sem cookies onde as informações da sessão do cliente são armazenadas,
Ø ture usa o modo sem cookies,
Ø false Use o modo Cookie, este é o valor padrão,
Ø timeout define o número de minutos após os quais o servidor entrega automaticamente as informações da sessão. O padrão é 20 minutos.
stateConnectionString define o nome do servidor e o número da porta usados ao armazenar informações da sessão no serviço de estado, por exemplo: "tcpip=127.0.0.1:42424". Este atributo é obrigatório quando o valor de mode é StateServer.
sqlConnectionString define a string de conexão ao conectar-se ao SQL Server. Por exemplo "fonte de dados= localhost;Segurança Integrada=SSPI;Catálogo Inicial=northwind". Este atributo é obrigatório quando o valor de mode é SQLServer.
stateNetworkTimeout define o número de segundos ociosos após os quais a conexão TCP/IP entre o servidor Web e o servidor que armazena as informações de estado é desconectada ao usar o modo StateServer para armazenar o estado da sessão. O valor padrão é 10 segundos.
O armazenamento do status da sessão do cliente no asp.NET é mostrado em nossa introdução ao modelo de sessão acima. Você pode descobrir que o status da sessão deve ser armazenado em dois locais, ou seja, o cliente e o servidor. O cliente é responsável apenas por salvar o SessionID do site correspondente, enquanto outras informações da sessão são salvas no servidor. No asp, o SessionID do cliente é armazenado na forma de um cookie. Caso o utilizador opte por desativar os cookies nas configurações do navegador, então não poderá usufruir da comodidade da sessão, podendo mesmo não conseguir aceder a determinados websites. Para resolver os problemas acima, o método de armazenamento de informações de sessão do cliente no asp.NET é dividido em dois tipos: Cookie e Cookieless.
No asp.NET, por padrão, os cookies ainda são usados para armazenar informações de sessão no cliente. Se quisermos usar Cookieless para armazenar informações de sessão no cliente, o método é o seguinte:
Encontre o diretório raiz do aplicativo web atual, abra o arquivo Web.Config e encontre o seguinte parágrafo:
< estado da sessão
modo = "InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString = "fonte de dados = 127.0.0.1; Trusted_Connection = sim"
sem cookies = "falso"
tempo limite = "20"
/>
O cookieless="false" neste parágrafo é alterado para: cookieless="true". Desta forma, as informações da sessão do cliente não são mais armazenadas por meio de cookies, mas são armazenadas através da URL. Feche o IE atual, abra um novo IE e revisite o aplicativo da web agora mesmo. Você verá algo semelhante ao seguinte:
Dentre eles, o que está marcado em negrito em http://localhost/MyTestApplication/(ulqsek45heu3ic2a5zgdl245 )/default.aspx é o ID da sessão do cliente. Observe que essas informações são adicionadas automaticamente pelo IIS e não afetarão as conexões normais anteriores.
Preparativos para armazenar o estado da sessão no lado do servidor em asp.NET:
Para vivenciar melhor o fenômeno experimental, você pode criar uma página chamada SessionState.aspx e adicionar os seguintes códigos a <body></body>.
<scriptrunat="servidor">
Sub Session_Add(remetente como objeto, e como EventArgs)
session("MinhaSessão") = text1.Value
span1.InnerHtml = "Dados da sessão atualizados! < P>Sua sessão contém: < font color=red>" & session("ToString() & "< /font>"
Finalizar sub
Sub CheckSession (remetente como objeto, eAs EventArgs)
Se (Sessão("MinhaSessão")Não É Nada) Então
span1.InnerHtml = "NADA, DADOS da sessão PERDIDOS!"
Outro
span1.InnerHtml = "Sua sessão contém: < font color= red>" & session("MySession").ToString() & "< /font>"
Terminar se
Finalizar sub
</script>
<formrunat="servidor"id="Form2">
< inputid="text1"type="text"runat="server"name="text1">
< inputtype="submit"runat="server"OnServerClick="Session_Add"
value="Adicionar ao estado da sessão " id="Submit1"name="Submit1">
< inputtype="submit"runat="server"OnServerClick="CheckSession"
value="Ver estado da sessão" id="Submit2"name="Submit2">
</form>
<hrsize="1">
< fontsize="6">< spanid="span1"runat="server" />< /font>
A página SessionState.aspx pode ser usada para testar se as informações da sessão foram perdidas no servidor atual.
Armazenando informações de sessão do servidor no processo Vamos voltar ao parágrafo anterior do arquivo Web.config:
< estado da sessão
modo = "InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString = "fonte de dados = 127.0.0.1; Trusted_Connection = sim"
sem cookies = "falso"
tempo limite = "20"
/>
Quando o valor do modo é InProc, indica que o servidor está utilizando este modo.
Este método é igual ao modo anterior do asp, ou seja, o servidor armazena informações da sessão no processo IIS. Quando o IIS for encerrado e reiniciado, essas informações serão perdidas. Mas este modo também tem sua maior vantagem, que é o maior desempenho. Como todas as informações da sessão são armazenadas no processo do IIS, o IIS pode acessar essas informações rapidamente. O desempenho desse modo é mais rápido do que armazenar informações da sessão fora do processo ou armazenar muitas informações da sessão no SQL Server. Este modo também é o modo padrão do asp.NET.
Ok, agora vamos fazer um experimento. Abra a página SessionState.aspx agora mesmo e insira alguns caracteres para armazená-los na sessão. Então, vamos reiniciar o IIS. Observe que não se trata de parar e reiniciar o site atual, mas de clicar com o botão direito do mouse no nó com o nome da máquina local no IIS e selecionar Reiniciar IIS. (Acho que quando usei o NT4, tive que reiniciar o computador para reiniciar o IIS. A Microsoft é realmente @#$%^&) Retorne à página SessionState.aspx, verifique as informações da sessão agora mesmo e descubra que as informações foram perdido.
Armazenando informações de sessão do servidor fora do processo Primeiro, vamos abrir as ferramentas de gerenciamento -> Serviços, encontrar o serviço chamado: asp.NET State Service e iniciá-lo. Na verdade, este serviço inicia um processo para salvar informações da sessão. Depois de iniciar este serviço, você pode ver um processo chamado aspnet_state.exe no Gerenciador de Tarefas do Windows-> Processos. Este é o processo onde salvamos as informações da sessão.
Em seguida, volte ao parágrafo acima no arquivo Web.config e altere o valor do modo para StateServer. Após salvar o arquivo, reabra um IE, abra a página SessionState.aspx e salve algumas informações na sessão. Neste momento, vamos reiniciar o IIS e voltar à página SessionState.aspx para verificar as informações da sessão agora mesmo e descobrir se elas não estão perdidas.
Na verdade, esta forma de armazenar informações da sessão fora do processo não significa apenas que as informações podem ser armazenadas fora do processo da máquina local, mas também que as informações da sessão podem ser armazenadas nos processos de outros servidores. Neste momento, você não só precisa alterar o valor do modo para StateServer, mas também configurar os parâmetros correspondentes em stateConnectionString. Por exemplo, seu cálculo é 192.168.0.1. Se você deseja armazenar a sessão no processo do computador com endereço IP 192.168.0.2, você precisa configurá-lo assim: stateConnectionString="tcpip=192.168.0.2:42424". Claro, não se esqueça de instalar o .NET Framework no computador 192.168.0.2 e iniciar o serviço asp.NET State Services.
Armazenando informações de sessão do servidor no SQL Server Primeiro, vamos fazer alguns trabalhos preparatórios. Inicie os serviços de proxy do SQL Server e do SQL Server. Execute um arquivo de script chamado InstallSqlState.sql no SQL Server. Este arquivo de script criará um banco de dados no SQL Server especificamente para armazenar informações de sessão e um trabalho de agente do SQL Server que mantém o banco de dados de informações de sessão. Podemos encontrar esse arquivo no seguinte caminho:
[unidade do sistema]winntMicrosoft.NETFramework[versão]
Em seguida, abra o analisador de consultas, conecte-se ao servidor sql, abra o arquivo agora mesmo e execute-o. Aguarde um momento e o banco de dados e o trabalho serão criados. Neste momento, você pode abrir o Enterprise Manager e ver que um novo banco de dados chamado ASPState foi adicionado. Mas existem apenas alguns procedimentos armazenados neste banco de dados e não há tabela de usuários. Na verdade, as informações da sessão são armazenadas na tabela ASPStateTempSessions do banco de dados tempdb, e outra tabela ASPStateTempApplications armazena as informações do objeto do aplicativo em asp. Essas duas tabelas também foram criadas pelo script agora há pouco. Além disso, verifique Gerenciamento-> Agente do servidor SQL-> Trabalhos e descubra que também há um trabalho adicional chamado ASPState_Job_DeleteExpiredSessions. Este trabalho, na verdade, exclui informações de sessão expiradas da tabela ASPStateTempSessions a cada minuto.
A seguir, retornamos ao arquivo Web.config e modificamos o valor do modo para SQLServer. Observe que você também precisa modificar o valor de sqlConnectionString ao mesmo tempo. O formato é:
sqlConnectionString="fonte de dados=localhost; Segurança Integrada=SSPI;"
A fonte de dados refere-se ao endereço IP do servidor SQL Server. Se o SQL Server e o IIS forem a mesma máquina, basta escrever 127.0.0.1. Segurança Integrada=SSPI significa usar autenticação integrada do Windows. Desta forma, o acesso ao banco de dados será feito como asp.NET, você pode obter melhor segurança do que o método de autenticação do sql server usando userid=sa;password=sex. . Obviamente, se o SQL Server estiver sendo executado em outro computador, pode ser necessário manter a consistência da autenticação em ambos os lados por meio do domínio do Active Directory.
Novamente, vamos fazer um experimento. Adicione informações da sessão a SessionState.aspx e descubra que as informações da sessão já existem no SQL Server. Mesmo se você reiniciar o computador, as informações da sessão não serão perdidas. Agora você viu completamente a aparência das informações da sessão e elas estão armazenadas no SQL Server. O que você pode fazer depende do seu desempenho.
Resumo 3. Configurações gerais de autenticação de formulário asp.net
Configurações gerais para autenticação de formulário asp.net:
1: No web.config, adicione autenticação de formulário;
<modo de autenticação="Formulários">
<forms name="auth" loginUrl="index.aspx" timeout="30"></forms>
</autenticação>
<autorização>
<negar usuários=" />
</autorização>
2: Se houver uma página de registro, usuários anônimos deverão poder ligar para a página de registro para se registrar;
O código a seguir deve estar entre <configuration><system.web> e não deve ser incluído entre <system.web>..</system.web>;
----------------Indica que usuários anônimos têm permissão para acessar a página userReg.aspx.
<caminho de localização="userReg.aspx">
<sistema.web>
<autorização>
<permitir usuários=" />
</autorização>
</system.web>
</local>
3. Após o login bem-sucedido, um ticket de verificação de identidade deverá ser criado para indicar que o usuário legal autenticado foi aprovado;
if (login bem-sucedido)
System.Web.Security.FormsAuthentication.SetAuthCookie(nome de usuário, falso);
4. Acesse o arquivo Web.config Você pode acessar o arquivo Web.config usando a coleção de cadeias estáticas ConfigurationSettings.AppSettings. Exemplo: Obtenha a cadeia de conexão estabelecida no exemplo acima. Por exemplo:
string estática protegida Isdebug = ConfigurationSettings.AppSettings["scon"]
Otimização de desempenho asp.Net.
(1).Selecione o método de armazenamento do estado da sessão
Configure no arquivo Webconfig:
<modo sessionState="???" stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString = "fonte de dados = 127.0.0.1; Trusted_Connection = sim"
cookieless="falso" timeout="20"/>
O ASP.NET possui três maneiras de armazenar informações de estado da sessão:
1. Armazenado no processo: modo de atributo = InProc
Recursos: Possui o melhor desempenho e a velocidade mais rápida, mas não pode ser compartilhado entre vários servidores.
2. Armazenado no servidor de estado: atributo mode = "StateServer"
Recursos: Use este método quando as informações da sessão do usuário precisarem ser mantidas nos servidores.
Mas as informações são armazenadas no servidor de estado e, quando o servidor de estado falhar, as informações serão perdidas
3. Armazenado no SQL Server: atributo mode = "SqlServer"
Características: A carga de trabalho aumentará, mas as informações não serão perdidas.
Mais uma coisa:
I. Como algumas páginas não exigem estado de sessão, o estado de sessão pode ser desabilitado:
O código é o seguinte: <%@ Page EnableSessionState="false" %>
II. Se a página precisar acessar variáveis de sessão, mas não tiver permissão para modificá-las, você poderá definir o status da sessão da página como somente leitura:
O código é o seguinte: <%@ Page EnableSessionState="false" %>
Ao usá-lo, você pode escolher um determinado método de acordo com a situação específica
(2).Use Page.IsPostBack
Page.IsPostBack indica se é retornado do cliente. Ao ser executado pela primeira vez, seu valor não é retornado.
É falso, quando um evento na página é acionado ou a página é atualizada, o valor de Page.IsPostBack torna-se verdadeiro porque é postback;
Geralmente usado em: método Page_Load:
private void Page_Load(Remetente do objeto,EventArgs e)
{
if(!Page.IsPostBack)
{
....; //Código para inicializar a página. Esses códigos são executados quando a página é inicializada pela primeira vez e quando postada novamente pela segunda vez,
//Não será executado novamente. Melhore a eficiência.
}
}
Freqüentemente, IsPostBack precisa ser usado porque alguns controles precisam manter seu estado após a inicialização.
Por exemplo: DropDownList, se inicializado sempre, não importa a opção que o usuário selecione, ele será inicializado com o valor padrão.
(3). Evite usar controles de servidor.
1. Para obter informações gerais de exibição estática, tente não usar controles do lado do servidor para exibi-las, pois os controles do lado do servidor precisam ser postados de volta no servidor para execução.
Isso reduzirá a eficiência da execução do programa. Geralmente, pode ser exibido com <DIV>.
Se forem usados controles do lado do servidor, a remoção de: runat="server" também melhorará a eficiência.
2. Desative a visualização de estado dos controles do lado do servidor. Alguns controles não precisam manter seu estado. Você pode definir suas propriedades: EnableViewState=false;
Se o controle de página inteiro não precisar manter uma visualização de estado, você poderá definir a visualização de estado da página inteira como falsa:
O código é o seguinte: <%@ Page EnableViewState="false"%>
3. Configure no arquivo Web.Config:
As sessões asp.NET podem ser configuradas no elemento Sessionsstate em Web.config ou Machine.config.
Aqui está um exemplo das configurações em Web.config:
<Sessionsstate timeout="10" cookieless="false" mode="Inproc" />
(4). Evite usar DataGrid.
Todo mundo sabe que o DataGrid é poderoso. No entanto, embora seja poderoso, também aumenta a sobrecarga de desempenho. Geralmente use outros controles: DataList
Ou o controle do repetidor pode conseguir isso, tente não usar o DataGrid.
(5).Operações de string
1. Evite que as operações de embalagem sejam menos eficientes.
Por exemplo, execute dois trechos de código:
string teste="";
para(para int i=0;i<10000;i++)
{
teste = teste + eu;
}
e
string teste="";
para(para int i=0;i<10000;i++)
{
teste = teste + i.ToString();
}
O trecho de código abaixo é obviamente mais eficiente Como i é um número inteiro, o sistema deve primeiro encaixotar e converter i em um tipo de string antes de conectar.
Os leitores podem copiá-lo para suas próprias máquinas e testá-lo.
2. Use a classe StringBulider
Ao realizar a concatenação de strings: string str = str1 + str2 + ....;
Geralmente, para mais de três conexões, é melhor usar StringBuilder em vez da classe string para evitar a recriação de objetos string.
perda de desempenho.
Geralmente usado ao montar instruções SQL: StringBulider.
Os leitores podem testá-lo em suas próprias máquinas.
3. Use o mínimo possível:
tentar
{}
pegar
{}
finalmente
{}
Declaração. A eficiência de execução desta declaração é relativamente baixa.
(6) Otimização do uso do ADO.Net
1. As conexões com o banco de dados são abertas e fechadas. Abra quando uma conexão for necessária e feche a conexão imediatamente após acessar o banco de dados.
Por exemplo, vejamos dois trechos de código:
EU.
DataSet ds = new DataSet();
SqlConnection MyConnection = new SqlConnection("servidor=localhost; uid=sa; pwd=; banco de dados=NorthWind");
SqlCommand meuComando = new SqlCommand(strSql,MinhaConexão);
SqlDataAdapter meuAdapter=new SqlDataAdapter(queryStr,connectionStr);
MyConnection.Open(); //Abre a conexão
for(int i=0;i<1000;i++) //loop for simula operações de lógica de negócios antes de obter dados
{
Thread.Sleep(1000);
}
meuAdapter.Fill(ds);
for(int i=0;i<1000;i++) //loop for simula operações de lógica de negócios após a obtenção de dados
{
Thread.Sleep(1000);
}
MyConnection.Close(); //Fecha a conexão
II.
DataSet ds = new DataSet();
SqlConnection MyConnection = new SqlConnection("servidor=localhost; uid=sa; pwd=; banco de dados=NorthWind");
SqlCommand meuComando = new SqlCommand(strSql,MinhaConexão);
SqlDataAdapter meuAdapter=new SqlDataAdapter(queryStr,connectionStr);
for(int i=0;i<1000;i++) //loop for simula operações de lógica de negócios antes de obter dados
{
Thread.Sleep(1000);
}
MyConnection.Open(); //Abre a conexão
meuAdapter.Fill(ds);
MyConnection.Close(); //Fecha a conexão
for(int i=0;i<1000;i++) ////O loop for simula a operação da lógica de negócios após a obtenção dos dados
{
Thread.Sleep(1000);
}
O código II de exibição é muito melhor que o código I. O código I ocupa a conexão antecipadamente. Se houver muitos usuários, o pool de conexões provavelmente estará cheio. Em casos graves, pode ocorrer um acidente.
2. Consulta de banco de dados
I. Gere instruções SQL diretamente. O SQL Server precisa compilá-lo sempre e não haverá uma grande melhoria no desempenho. Além disso, não é suficientemente seguro. Facilmente atacado.
II. Use o comando sql com parâmetros. Dessa forma, o SQL Server compila apenas uma vez e os comandos compilados podem ser reutilizados para diferentes parâmetros. Melhor desempenho.
III. Use procedimentos armazenados do SQL Server. É independente e fácil de modificar e manter. Ele pode executar a função de enviar instruções várias vezes ao mesmo tempo.
fluxo. Os procedimentos armazenados não são necessariamente mais eficientes que as instruções. Se a lógica de negócios for muito complexa, às vezes as instruções são mais eficientes que os procedimentos armazenados.
(6).
Existem dois tipos de cache: cache de página e cache de API.
1. Use cache de página e cache de fragmentos
<%@ OutputCache Duration="5" VaryByParam="None"%>
<%@ Duração do OutputCache=60 VaryByParam=”TextBox1,TextBox2” %>
Nota: Duração serve para definir o tempo de expiração do Cache;
VarByParam é se a configuração muda de acordo com os parâmetros. Quando Nenhum, todos os parâmetros usam o mesmo Cache.
Ao definir TextBox1, armazene-os em cache separadamente de acordo com diferentes valores de TextBox1, quando houver vários parâmetros, armazene-os em cache em combinação;
2.Cache de API. para uso em aplicações
I. Um exemplo de uso de cache:
http://blog.csdn.net/chengking/archive/2005/10/03/494545.aspx
II. Preste atenção à diferença entre Page.Cache e HttpContext.Current.Cache ao usar:
Eles se referem ao mesmo objeto. Em Page, use Page.Cache. Se você usar em global.asax ou em sua própria classe: HttpContext.Current.Cache. Em alguns eventos, porque não há HttpContext, use HttpRuntime.Cache.
