Existe uma frase que resume bem a necessidade de acesso à dados: “A informação certa, para a pessoa certa, na quantidade certa e no momento certo”.

Esta frase apresenta alguns aspectos importantes:

• A informação certa: A informação deve estar correta, isto é, deve ser confiável. A informação é utilizada para a tomada de decisões, nos mais variados níveis de uma empresa. Se a informação estiver incorreta, as decisões serão equivocadas e não irão gerar os resultados esperados. Pior do que não ter a informação é ter informação incorreta, não confiável.
• Para a pessoa certa: Independente do nível hierárquico, quer seja o operário da fábrica ou o presidente da empresa, todos precisam de informação para trabalhar e alcançar os resultados desejados. A informação correta precisa estar a disposição para as pessoas que dela necessitam.
• Na quantidade certa: Informação demais também é um problema e pode atrapalhar ao invés de ajudar. E hoje as informações vem das mais diversas fontes. Internet, e-mail, relatórios, banco de dados da empresa, arquivos do Office, jornais, revistas, livros, manuais técnicos. Precisamos garimpar as informações que realmente são necessárias ao nosso trabalho.
• No momento certo: Este é um aspecto fundamental. Lembro-me da época em que somente tínhamos o Mainframe e um “bando” de terminais espalhados pela empresa. Você solicitava um novo relatório para a turma do CPD. Duas semanas depois vinha o relatório. Hoje, evidentemente, esta situação é inaceitável. Precisamos da informação instantânea, sempre a disposição.

Quando as empresas começaram a descentralizar seus ambientes computacionais, passando do modelo Mainframe/Terminal para um modelo Cliente/Servidor com redes locais, novas possibilidades, e também problemas, começaram a surgir. Bancos de dados departamentais não integrados, diferentes formatos de dados, aplicações Cliente/Servidor rodando em cada estação de trabalho, etc, isso fez com que a informação ficasse distribuída por toda a empresa e não mais centralizada no Mainframe.

Um ambiente descentralizado é mais flexível, mas em contrapartida é mais difícil de gerenciar e de manter o controle. A medida que o volume de informações começou a crescer, ficou difícil ter acesso aos dados de diferentes departamentos de uma maneira consistente e rápida. Na Figura 10.1 temos uma pequena ilustração deste ambiente:

Figura 10.1 Dados de múltiplas e heterogêneas fontes.

Além de múltiplas fontes de dados, temos diferentes formatos de dados. Evidentemente que a estrutura de um arquivo de mensagens de correio é muito diferente da estrutura de uma planilha do Excel, por exemplo.

Para que possamos criar aplicações que acessam dados de diversas fontes, precisamos de tecnologias capazes de acessar dados de fontes tão diversas como o Mainframe e um documento do Microsoft Word ou uma planilha do Microsoft Excel. O Framework .NET fornece, principalmente através do namespace System.Data, uma série de classes para conexão e manipulação de dados dos mais variados formatos. Este conjunto de classes também é conhecido como ADO.NET.

Neste capítulo vamos estudar as classes que dão acesso a fontes de dados estruturadas, que seguem o modelo de dados relacionais. Podemos citar como exemplos de bancos de dados relacionais, o Microsoft Access, o SQL Server 2000, o ORACLE, o DB2 da IBM, etc. 

Nota: Para maiores detalhes sobre o modelo de dados relacionais, consulte o Anexo II.

Quais as principais diferenças do ADO.NET em relação ao ADO?

Com ADO estabelecíamos uma conexão com uma fonte de dados e utilizávamos, ou o método Open do Objeto Connection ou um objeto do tipo Command, para executar um comando SQL e retornar dados, no formato de uma tabela, para um objeto do tipo Recordset. A característica principal é que para trabalhar com os dados e fazer alterações nos mesmos, precisamos estabelecer uma conexão com o banco de dados.

Com ADO.NET temos um modelo de dados “desconectado”.  O protocolo HTTP é conhecido como Connection Less. Ao solicitar uma página, é estabelecida uma conexão com o servidor Web, os arquivos e imagens necessários são solicitados e enviados para o navegador do cliente e a conexão é fechada, por isso o Connection Less, pois não é mantida uma conexão permanente entre o servidor Web e o navegador do cliente. Esta natureza “desconectada” da Web, causa alguns inconvenientes quando desenvolvemos aplicações de banco de dados.

ADO.NET resolve este problema, fornecendo uma série de objetos que permitem que os dados, uma vez carregados para o navegador do cliente, sejam manipulados, mesmo sem existir uma conexão permanente com o banco de dados. Uma vez feita as alterações, inclusões ou exclusões necessárias, podemos, facilmente, sincronizar os dados que estão no cliente com o banco de dados no servidor. Veremos nos Capítulos 10 e 11, exemplos de métodos para sincronização dos dados.

O principal objeto do modelo ADO, para trabalhar com dados, é o objeto RecordSet. Para exibir os dados de um objeto RecordSet, precisamos escrever uma boa quantia de código. Com ADO.NET, o principal objeto , que funciona como um Container para dados, é o DataSet, o qual pode conter uma ou mais tabelas (o objeto RecordSet somente pode conter uma tabela) e também os relacionamentos entre as tabelas e informações sobre chaves primárias e chaves estrangeiras.

Com o modelo “desconectado” do ADO.NET, não utilizamos cursores, nem no lado cliente, nem no lado servidor. As classes de acesso a dados fornecem os mecanismos necessários para a manipulação dos dados. O formato adotado para armazenar os dados no cliente é o XML, um padrão amplamente aceito pela industria. Com ADO, ao utilizar tecnologias como RDS para trabalhar com dados desconectados, temos um formato proprietário para os dados, formato este que somente é aceito pelo Internet Explorer.

Nota: Para maiores informações sobre Tabelas, Atributos, Chaves Primárias, Chaves Estrangeiras e Relacionamentos entre tabelas, consulte o Anexo II.

Neste capítulo vamos aprender a utilizar alguns objetos básicos para o acesso a dados relacionais, mais especificamente, a dados do SQL Server e do Microsoft Access. Veremos como estabelecer uma conexão com o banco de dados, acessar dados de uma ou mais tabelas e exibir estes dados em uma página ASP.NET.

Para exibição dos resultados obtidos, estaremos utilizando o Web Server Control – DataGrid. Estudaremos este controle em detalhes. Veremos que o controle DataGrid facilita, enormemente, a tarefa de exibir dados em uma página ASP.NET. No nosso exemplo mais simples, veremos que, o que no ASP 3.0 exige várias linhas de código, no ASP.NET, com o controle DataGrid, pode ser feito em uma única linha de código.

Nota: Os exemplos deste capítulo serão criados na pasta D:\Inetpub\wwwrooot\Chap10. Para acessar uma  página, dentro desta pasta, por exemplo: Chap10Ex1.aspx, utilize o seguinte endereço: http://localhost/Chap10/Chap10Ex1.aspx. A seguir descrevo os bancos de dados que serão utilizados nos exemplos deste e dos próximos capítulos.