ADO .NET - Recomendações para estratégia de acesso a dados

Se você está iniciando o aprendizado ou migrando para a plataforma .NET, pode estar confuso quando o assunto é acesso a dados. Motivos não faltam, afinal você tem a sua disposição diversas opções na plataforma .NET para realizar acesso a dados com classes e métodos distintos: DataSets, DataReaders, XML, TableAdapters, DataAdapter, Command, etc.

Diante de tantas opções, a dúvida sobre qual delas é a melhor escolha para a sua aplicação, é algo comum para os iniciantes e mesmo para quem já usa o plataforma .NET há algum tempo. Afinal o que seria mais recomendado para uma aplicação WIndows Forms? DataSet ou DataRead ? E para uma aplicação Web que usa os Web Forms?

Neste artigo pretendo apresentar as recomendações para estratégia de acesso a dados sugeridas pela Microsoft no artigo: http://msdn2.microsoft.com/en-us/library/8fxztkff(VS.71).aspx , e, assim, lançar um pouco de luz sobre este tema com o objetivo de ajudar a esclarecer(não esgotar) o assunto. Vamos lá...

Um pouco sobre ADO .NET
O modelo de acesso a dados usado pela ADO .NET pode ser resumido da seguinte forma:

Você abre uma conexão;
Obtêm os dados ou realiza uma operação;
Você fecha a conexão;
Muito simples não é mesmo ? Para trabalhar com este modelo a ADO .NET fornece duas estratégias básicas:

Armazenar os dados em um dataset , que é um cache de dados em memória de registros nos quais você pode trabalhar enquanto esta desconectado da fonte de dados. Para usar um dataset você cria uma instância do mesmo e usa um data adapter ou TableAdapter para preencher o dataset a partir da fonte de dados. Feito isso você pode trabalhar com os dados no dataset , realizar operações , exibir os dados em formulários , etc.
Realizar operações diretamente no banco de dados através de comandos SQL ou stored procedures. Este modelo exige que você esteja conectado a fonte de dados e utilize o objeto Command incluindo uma instrução SQL ou uma referência a uma stored procedure para em seguida executar o comando e realizar a operação desejada. (Os comandos de dados ADO.NET (data commands) permitem a execução de comandos diretamente contra uma base de dados sem necessitar de um dataset ou de um data adapter.)
Nota: O objeto DataReader é usado somente para leitura de dados de forma conectada e percorre os dados até o fim em um único sentido (forward-only) e no modo somente leitura (read-only). O DataReader consome menos recursos do que o dataset e oferece uma acesso mais rápido que o objeto dataset mas não pode efetuar alterações na fonte de dados original, sendo usado para acessar os dados de forma rápida e para apresentá-los sempre atualizados.

Vantagens do modelo DataSet:

*Permite trabalhar com múltiplas tabelas, onde você pode trabalhar com uma única tabela ou navegar entre elas;
*Permite manipular dados de múltiplas fontes. As tabelas em um dataset podem representar dados originados de diferente fontes de informação como banco de dados, arquivos XML, planilhas ,etc. Uma vez reunidos no dataset você pode manipular as informações e relacioná-las em um formato homogêneo como se fosse tivessem vindo de uma única fonte de dados;
*Permite mover dados entre camadas em uma aplicação distribuída;
*Permite a reutilização de informação. Um dataset permite que você trabalhe com os mesmos registros de dados repetidamente sem ter que acessar novamente a fonte de dados realizando operações de ordenação , filtragem e paginação de dados;
*Permite programar de uma forma mais aderentes a OOP. Quando você trabalhar com datasets você pode gerar classes que representam a estrutura de objetos do seu negócio. Esta prática torna a programação mais fácil , clara e menos propensa a erros;

Vantagens do modelo de acesso direto:

*Funcionalidade extra. Algumas operações , como comandos DDL, somente podem ser executadas neste modelo;
*Maior controle sobre as operações. Com a utilização de comandos, e um DataReader se você for somente ler os dados, você obtêm um controle maior sobre como e quando uma instrução SQL ou uma stored procedure é executada e o quais os resultados e valores serão retornados;
*Menor consumo de recursos(less overhead). No modelo de acesso direto você não usa um dataset, e com isso reduz o consumo de recursos em sua aplicação , pois um dataset requer memória para ser usado.

Qual modelo devemos usar ? Em quais circunstâncias um modelo é mais indicado que o outro ?

Nota: De forma geral a recomendação para acesso a dados tem a seguinte premissa: Abrir a conexão o mais tarde e fechar o mais cedo possível.

1- Windows Forms

Em aplicações WIndows Forms você, quase sempre, deve usar um dataset:

*Aplicações Windows Forms são geralmente usadas em clientes ricos (desktops) onde os formulários não são criados e descartados em cada operação do usuário como no caso dos web forms;
*Aplicações Windows Forms também oferecem um cenário de acesso a dados que se beneficiam da manutenção de um cache de registros, como a exibição de registros um a um em um formulário;

Especificamente você deve usar os datasets nos seguintes cenários:

*Se você for trabalhar com os mesmos registros repetidamente, como efetuar a navegação entre registros;
*Se você for usar a arquitetura data-binding Windows Forms que foi desenhada para trabalhar com datasets;

Você deve usar uma consulta TableAdatper ou comando de dados nos seguintes cenários:

*Se você for obter um valor escalar de um base de dados;
*Se você for realizar uma operação de não consulta como um comando DDL;
*Se você for obter dados somente leitura para exibir em um formulário;

DDL - Data Definition Language (DDL) - São usados para definir o esquema e estrutura do banco de dados, exemplos:

*CREATE - para criar objetos em um banco de dados;
*ALTER - alterar a estrutura de um banco de dados;
*DROP - deletar objetos de um banco de dados;
*RENAME - renomear um objeto;

2- Web Forms

Em aplicações Web Forms você deve usar os comandos de dados para realizar operações e um DataReader para exibição de dados:

*As páginas Web Forms e seus controles e componentes são recriados a cada vez que a página realiza uma ida e volta ao servidor de forma que não é muito eficiente criar e preencher um dataset a cada acesso , a menos que você deseje efetuar o cache de dados entre os round trips;

Especificamente você deve usar os datasets nos seguintes cenários:

*Você desejar trabalhar com múltiplas tabelas separadas ou tabelas de diferentes fontes de dados;
*Você desejar trocar dados com outra aplicação ou componente como um XML ou Web Service;
*Você necessita realizar um processamento demorado com cada registro que obter da base de dados. (Se você usar um datareader nesta situação a conexão ficará aberta por um longo período de tempo afetando o desempenho da sua aplicação.)
*Você precisa processar registros interdependentes como efetuar consultas em registros relacionados;
*Você deseja realizar operações XML como transformações XSLT nos dados;

3- XML Web Services

Como XML Web Services são aplicações Web ASP .NET você deve usar o mesmo modelo que o indicado para

as páginas Web Forms:

*Um XML Web Service é criado e descartado a cada chamada com isso o modelo usado é geralmente o mesmo indicado para as página Web Forms. Note porém que os XML Web Services são objetos da camada do meio (middle-tier) e o seu objetivo é intercambiar dados com outras aplicações na web. Por isso...

Considere a utilização de um dataset se:

*O XML Web Service envia e recebe dados;
*Existir quaisquer um dos cenários indicados para a utilização de um dataset indicado para os web forms;

Use os comandos de dados e/ou um DataReader nos seguintes cenários:

*O XML Web Service for retornar um valor escalar;
*O XML Web Service esta realizando uma operação de não consulta como um comando DDL;
*O XML Web Service esta chamando uma stored procedure;

Uma palavra final sobre a utilização de acesso a dados com Crystal Reports

A escolha do modo de acesso a dados com relatórios Crystal Reports em sua aplicação irá afetar a atualização do relatório e a sua distribuição.

Obter os dados de uma fonte conectada e os colocar diretamente no relatório : Usando este método os relatórios será afetados por quaisquer alterações irão exigir uma novo deploy do relatório;

Definir as tabelas e os campos usados no relatório, criar um dataset e passar para o relatório: Este método requer uma maior trabalho de configuração, definição de conexão com o banco de dados, execução de consultas contra o banco de dados e utilização do método SetDataSource;

A palavra final quanto a qual modelo usar envolve a escolha do visualizador (viewer):

*O primeiro modelo cria um relatório no qual todas as definições da fonte de dados estão embutidas e pode ser usada com o viewer report para Windows ou Web;
*O segundo modelo pode ser visualizado somente usando um programa desenhado para coletar e expor os dados contidos;

Este é um resumo básico que não contempla os novos recursos da ADO.NET Entity Framework e do LINQ.

Estamos conversados...

Referências:

http://www.microsoft.com/brasil/msdn/Tecnologias/adonet/DadosADONETSQL.mspx
ADO.NET - A arquitetura de dados desconectada e a concorrência de dados
http://blogs.msdn.com/data/archive/2007/04/28/microsoft-s-data-access-strategy.aspx