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." [...] continue lendo...