Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Revista MSDN Magazine Edição 24 - DataSet X Coleções
Artigo Originalmente Publicado na MSDN Magazine Edição 24
Clique aqui para ler todos os artigos desta edição
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
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.
"
Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Dino Esposito
Dino Esposito (dino2@wintellect.com) é instrutor e consultor e reside em Roma, Itália. Dino é autor de Building Web Solutions with ASP.NET and ADO.NET e Applied XML Programming for Microsoft .NET, ambos da Microsoft Press (2002).
