pg" width=34 border=0>bustas e escaláveis, usando o mínimo de esforço possível. Conheceremos os poderosos recursos de cache de dados, uso efetivo de stored procedures, connection pooling, ajustes de configuração e outras técnicas avançadas. Nesta primeira parte, você aprenderá como usar DataSets em memória para evitar consultas desnecessárias ao servidor SQL e otimizar assim o tráfego de dados. Você também conhecerá um pouco sobre o interessante recurso de connection pooling do ADO.NET.

Criando a aplicação

Para construir os exemplos desta série, utilizarei o Visual Studio .NET e o SQL Server 2000 como banco de dados. As aplicações serão feitas usando C#, mas podem ser facilmente escritas em VB.NET, caso queira utilizar essa linguagem.

No Visual Studio, clique em File>New>Project (ou aperte Shift+Ctrl+N) e na janela New Project escolha ASP.NET Web Application no item Visual C# Projects (Figura 1). Na opção Location dê um nome para aplicação e a seguir clique em Ok. Neste momento, o Visual Studio criará um diretório virtual no IIS, localizado por padrão em c:\Inetpub\wwwroot\.

 

image001.png

Figura 1. Criando uma nova aplicação ASP.NET no Visual Studio .NET.

Configurando a conexão com ADO.NET

O ADO.NET é a tecnologia de acesso a dados usada no .NET Framework. Para acessar um servidor de banco de dados fazemos uso de um provider. Cada provider está representado no formato de um conjunto de componentes, que implementam interfaces predefinidas pelo ADO.NET.

O .NET Framework 1.1 é distribuído com quatro providers: SQL Server, OleDB, ODBC e Oracle. Para acessar o SQL Server, poderíamos usar qualquer um dos três primeiros providers, mas já vou deixar claro aqui a primeira regra para otimização ASP.NET: para acesso ao SQL Server, use o provider específico para SQL. O ganho de performance chega a 40% comparado aos demais, visto que esse provider usa o TDS (Tabular Data Stream), um formato nativo do SQL Server para comunicação. Os outros dois providers (OleDb e ODBC) exigem a utilização de uma camada extra de comunicação. A única vantagem em usar esses providers seria poder trocar de banco de dados (por exemplo, para Access) sem causar um efeito colateral muito grande no código da aplicação.

Sabendo disso, vamos configurar uma conexão ADO.NET para o SQL Server. A partir da ToolBox, coloque um SqlConnection no Web Form. Selecione o componente e na janela Properties escolha New Connection na propriedade ConnectionString.

No editor que aparece (Figura 2), informe o nome ou endereço IP do servidor na primeira caixa de entrada (digite "localhost" se o SQL Server estiver rodando na mesma máquina). Em User name e Password informe o usuário e senha padrão para acesso ao banco ("sa" e senha em branco, lembrando que essa senha pode ter sido alterada durante a instalação do SQL Server). E finalmente, escolha o banco de dados Northwind e clique em Ok. Caso queira, clique no botão Test Connection para verificar se os parâmetros estão corretos.

 

image003.png

Figura 2. Configurando uma conexão ao SQL Server.

Pronto, já temos nossa conexão configurada! Antes de continuar, vamos agora examinar um importante recurso do ADO.NET, o uso de Connection Pooling.

Connection Pooling

Observe que em User name e Password informamos um usuário e senha padrão para acesso ao banco, mas poderíamos ter usado a autenticação integrada. No entanto, aqui vai a segunda dica valiosa para otimização: forneça um usuário e senha fixos, de forma que todos os usuários que conectem à aplicação utilizem as mesmas credenciais. Se for necessário restringir acesso a determinado usuário, defina isso na forma de autorizações no Web.Config. Fornecer um usuário fixo fará o ADO.NET utilizar de forma efetiva o recurso de Connection Pooling, sem ter perda de desempenho.

Connection Pooling é o mecanismo que permite ao ADO.NET "reaproveitar" conexões ao banco de dados. Imagine a seguinte situação: um usuário acessa a aplicação, conectamos ao BD para extrair informações e a exibimos no formulário. A seguir, fechamos a conexão e devolvemos o resultado ao browser. Como aplicações Web são state-less (sem estado), se esse mesmo ou outro usuário se conectar à aplicação, uma nova conexão precisará ser restabelecida. Conectar ao BD a cada requisição de usuário é literalmente um "suicídio" em ambiente Web, onde uma aplicação pode ter centenas e até milhares de conexões simultâneas.

O ADO.NET resolve isso de forma bastante elegante: após a página ser enviada ao browser, a conexão com o BD não é liberada, mesmo que você tenha chamado explicitamente o método ...

Quer ler esse conteúdo completo? Tenha acesso completo