Revista MSDN Magazine Edição 24 - DataSet X Coleções

DataSet X Coleções

Em software, cinco anos equivalem a uma era geológica. Há cinco anos, o Microsoft® .NET Framework tinha recentemente sido anunciado. Desde então, o DataSet emergiu como o objeto fundamental para executar uma variedade de tarefas relacionadas a dados em aplicações baseadas em .NET. Cinco anos atrás, o DataSet foi saudado como uma versão altamente melhorada do ADO Recordset. Como teríamos projetado uma camada de acesso a dados (DAL) antes do advento do .NET Framework? Seguramente a teríamos construído utilizando o ADO e nosso todo-poderoso objeto Recordset, o qual estava desconectado e XML serializável.

Poucos desenvolvedores estavam empregando coleções personalizadas, implementando um verdadeiro modelo de programação orientado a objeto ou procurando acesso a dados fortemente tipados, quando a programação orientada a objeto ou era um recurso para alguns programadores de C++ ou um “macete” avançado para os valentes desenvolvedores que usavam Visual Basic®.

Felizmente existem agora opções melhores para construir o back-end de um sistema empresarial, mas ainda temos que escolher a abordagem certa para esta tarefa. Vejamos como podemos tomar a melhor decisão.

Onde está o Problema?

Imagine que precisamos construir uma aplicação multi-camada, distribuída e baseada em .NET com três camadas de apresentação lógicas e serviços de interface, lógica de negócio com funcionalidades essenciais, e acesso a dados onde todas as coisas de banco de dados e mensagens acontecem. Para este tipo de aplicação, trabalhar em camadas é a solução. Se a camada mais baixa pudesse ignorar completamente as camadas superiores, o sistema estaria quase perfeito.

Quando projetamos um sistema baseado em camadas temos que considerar fatores como a habilidade para cascatear mudanças (como novos schemas de dados) através das camadas e o volume de tráfego extra envolvido quando dados são transferidos de uma camada para outra. Ainda mais: precisamos de uma camada para executar a lógica de negócio e de um DAL para prover as funções Create/Read/Update/Delete (CRUD) para o resto do sistema. Há dois modos principais para prover esta funcionalidade: a) pelo uso de uma ferramenta comercial de mapeamento Objeto / Relacional (O/R) ou b) rodando DAL.

Um mapeador O/R trabalha mapeando objetos personalizados para entidades em um banco de dados relacional. Através de um arquivo XML ou qualquer outra forma de repositórios de configurações, a ferramenta nos protege de confiar em qualquer conhecimento do banco de dados subjacente.  Trabalhamos com objetos específicos de domínio providos pelo mapeador. No lado oposto do espectro, encontra-se outra abordagem mais comum: construirmos nosso próprio DAL. Aqui nosso problema principal consiste em tomar uma decisão quanto ao mecanismo para passagem de dados.

Feitas todas as considerações, podemos dizer que vale a pena gastar algum tempo em quatro opções: DataSets, DataSets tipados, coleções personalizadas e XML puro. Usar texto XML puro é a opção menos atraente, embora proporcione integração plena com qualquer outra plataforma. É fracamente tipado, difícil de manter, executa pobremente e não é uma interface de programação poderosa no contexto de uma aplicação empresarial. Agora vejamos os prós e os contras das outras três opções.

DataSet - O Lado Bom

Francamente, escrever código de acesso a dados não é nada divertido. Na realidade, é freqüentemente enfadonho e tedioso, e exige que pensemos relacionalmente. Assim, quando a Microsoft introduziu o DataSet com a primeira versão do .NET Framework, todo o mundo olhou para a nova API com grande interesse, porque o DataSet e suas classes acompanhantes eram mais intuitivas. Além disso, há muitos assistentes e designers dentro e em torno do Visual Studio® .NET, para gerar código e injetá-lo diretamente nos arquivos fonte.

O DataSet é projetado para ser um container de propósito geral para qualquer informação que possa ser expressada em formato tabular - um container de informação relacional resultante de uma consulta a banco de dados. O DataSet tem a aparência e se comporta como um banco de dados em memória. Porém, não tem nenhuma noção de string de conexão, comandos, stored procedures, providers e logins. É puramente uma classe recipiente que armazena tabelas de dados e permite definir relações entre pares de tabelas nele contidas, as quais por sua vez, podem incluir constraints, construir índices e executar recuperação de dados e operações de filtro. Também suporta o conceito de expressões calculadas de colunas de tabelas.

O DataSet especificamente não foi projetado para trabalhar com bancos de dados, mas se ajusta bem em um cenário puro de banco de dados. O DataSet foi projetado para ser um datacentric container que pode ser preenchido com dados tabulares de virtualmente qualquer fonte: o arquivo de sistema, memória, dispositivos de tempo real e, é claro, consultas a bancos de dados.

O ADO.NET provê uma família de objetos que implementam uma ponte inteligente entre DataSets e bancos de dados. Estes objetos são conhecidos como Data Adapters. Chamando métodos em um Data Adapter, podemos executar comandos de banco de dados, usando o conteúdo do DataSet como entrada (batch update) ou como o stream de saída. Porém, apesar das facilidades do .NET Framework para conectar DataSets e bancos de dados, a classe DataSet continua sendo um objeto datacentric, com um modelo de programação orientado a banco de dados.

Com um objeto DataSet podemos empacotar e transmitir facilmente qualquer tipo de dados e combinar dados inter-relacionados de diferentes fontes e tabelas. Além disto, o DataSet é serializavel, tem capacidades XML integradas, suporte embutido para concorrência otimista e a habilidade para definir e controlar relações complexas entre tabelas nele contidas. Usando o DataSet para representar dados,  não precisamos mudar qualquer coisa em nossa API DAL ...