ASP.NET – Whidbey

Para quem ainda não conhece as novas “features” do ASP.NET, pode visitar site http://www.asp.net/whidbey/ e encontrará por lá algumas das novas facilidades/utilidades que a nova versão do ASP.NET proporcionará aos desenvolvedores.

Ainda existe uma área (http://www.asp.net/whidbey/pdc.aspx?tabindex=0&tabid=1) onde voce pode baixar os códigos fontes e as apresentações(“*.ppt”) apresentados no PDC2003. (Mas acredito que esses códigos não funcionam nas versões 2002/2003 do Visual Studio .NET).

E para quem quiser ir além, pode optar por comprar livros já publicados explicando essas melhorias:

* ASP.NET 2.0 Revealed
* A First Look at ASP.NET v 2.0

Mas as mudanças não param por aqui. Existem muitas coisas novas, principalmente quando falamos em termos de linguagem.

Em breve mostrarei algumas dessas novas “features” para o VB.NET e C#.

Dicas – Aplicações Web

Mostrarei abaixo algumas dicas que acredito ser importante quando falamos em performance de aplicações Web, utilizando ASP.NET:

1 – Desabilitar o Session State quando não for necessário. Mantenha-o ativo somente quando precisar modificar variáveis de sessão em uma determinada página.

2 – Selecionar o Session State cuidadosamente. Se estiver utilizando apenas um servidor, o mais viável é preservar o estado “In-Process”. Opte pelo emprego do SQL Server ou do State Server, somente quando estiver rodando uma série de servidores Web em conjunto.

3 – Evite “idas e voltas” excessivas no servidor. Essas “viagens” consumem tempo e recursos do servidor. Use-as somente quando precisar armazenar ou recuperar dados. Podemos utilizar os controles de servidor do ASP.NET e usar os processamento do lado do cliente para poupar tempo de processamento no servidor.

4 – Evite o ViewState em excesso. Quanto mais dados, maior o tamanho do ViewState. Como o Session State, desabilite-o quando não for necessário.

5 – Utilize o System.Text.StringBuilder para concatenação de Strings. Esse novo objeto é realmente muito performático quando necessitamos concatenar Strings.

6 – Utilize sempre o Option Strict = “True”. Isso torna seu código mais eficiente, pois força o “Early Binding”. Tendo essa imposição de tipos, evitamos a ligação tardia “Late Binding”, ou seja, irá conhecer qual o tipo desse objeto somente em runtime.

7 – Use Procedimentos Armazenados (Stored Procedures) na Base de Dados. O ADO.NET tem suporte completo ao uso das Stored Procedures, que podemos ter ganhos de desempenho, pois são executadas de forma nativa.

8 – Opte sempre pelo DataReader quando possível. Dentre os cursores disponíveis é o mais rápido. Lembrando apenas que ele é somente leitura.

9 – Utlizar o Cache sempre que possível. Quando o tráfego de dados é intenso, colocar esses dados em Cache pode poupar tempo de processamento do servidor, já que os dados são resgatados da memória RAM.

Essas foram algumas das vantagens que percebi lendo alguns artigos e nas aplicações que trabalho no dia-a-dia. Espero ajudar à voces.

“Hasheando” Passwords

Quando falamos em aplicações seguras, acho que não podemos descartar a opção de guardarmos na Base de Dados a senha “Hasheada”.

O FormsAuthentication nos dispõe um método para “hashear” a senha do usuário e com isso compararmos se está identica à da Base de Dados. O método para isso é o FormsAuthentication.HashPasswordForStoringInConfigFile() qual recebe como parametro o valor à ser “hasheado” e o tipo de Hash (“SHA1” ou “MD5”) . Exemplo:

FormsAuthentication.HashPasswordForStoringInConfigFile(Me.txtSenha.Text.Trim, “SHA1”)

Utilizando uma Senha como “israel”, veja o resultado:

MD5: 3F8454B7F2C12CEBB1622B6B0DFD1021
SHA1: 8F4F9F2DCBAF9BD8EE9E4D1A2CB971A04084157B

Importante: O Hash é irreversível, ou seja, uma vez “hasheado” não possível saber o que existe aí (até agora :P). Isso torna a aplicação bastante segura, uma vez que nem o sistema sabe qual a senha de um determinado usuário.

OBS.: Para utilizá-lo é necessário importar o System.Web.Security

Tags HTML

Aqui no trabalho nos deparamos com algo meio estranho à primeira vista, ou seja, quando tentavamos inserir códigos HTML dentro do WebForm, recebíamos um erro dizendo que isso não era possível devido à segurança do ASP.NET.

Depois de algumas vasculhadas pela Web (Google), encontramos a solução:

Para habilitarmos isso apenas em um determinada página, devemos colocar: ValidateRequest=False na diretiva da mesma. Mas se quiser deixar essa opção disponível para toda a aplicação, podemos definir isso diretamente no arquivo Web.Config, adicionando a seguinte linha: Pages ValidateRequest=”False”