artigo .net Magazine 47 - DAL hell

Boas Práticas

DAL hell

Discutindo a criação de componentes para acesso a banco de dados

Na edição 43 da .net Magazine, tivemos um artigo sobre a distribuição em camadas das diversas responsabilidades existentes em um aplicativo de acesso a banco de dados. Entre as camadas expostas naquele artigo, duas são importantes para o assunto que será abordado aqui: a camada de modelo (Model) e a de acesso a banco de dados (DAL – Data Access Layer).

A forma como a camada DAL é construída pode ser determinante em vários fatores na arquitetura de um aplicativo:

·         Modelo de classes: se a camada DAL é toda voltada para utilização de DataSet tipado, o desenho do modelo de classe com certeza será influenciado;

·         Quantidade de viagens (round trips) entre estrados: o ideal é que a camada DAL seja projetada para permitir ao cliente escolher em quantas viagens ele vai recuperar um determinado dado;

·         Quantidade de viagens entre a camada DAL e o banco de dados: está intimamente ligado com o item anterior. Imagine que a camada DAL permita ao cliente fazer uma consulta bem “gorda” de uma determinada informação. Ainda assim, recuperar essas informações no banco é uma outra estória. Caso essa informação venha de mais de uma tabela no banco de dados, provavelmente (mas não obrigatoriamente) o objeto de acesso ao banco de dados terá de ir mais de uma vez até o banco.

Dependendo do tamanho do aplicativo, do tipo de informação que está sendo tratada e da quantidade de usuários envolvidos, decidir sobre como construir a camada DAL pode não ser tão simples. Atualmente, para aplicativos grandes as opções existentes podem ser resumidas assim:

·         O acesso ao banco vai bem, mas é difícil de manter: isso é o mais comum. Normalmente componentes DAL que se enquadram aqui são muito instáveis e qualquer mexida pode causar um desastre;

·         O acesso ao banco vai mal e é difícil de manter: já tive o “prazer” de trabalhar em um aplicativo cuja camada DAL era um exemplar perfeito dessa categoria. Lembro-me bem, pois foi naquela época que acabei fazendo contato com o Dr. Jack Kevorkian...;

·         O acesso ao banco vai bem e é fácil de manter: o bom disso tudo é que sobra tempo para escrever ao papai noel e pedir ovos ao coelhinho da páscoa, não é mesmo?

·         DAL, o que é isso? Meu código de acesso ao banco de dados está lá no meio do meu código ASP ou ASP.NET: envie-me uma mensagem pelo correio eletrônico e eu lhe passarei o telefone do doutor que escrevi anteriormente, tudo bem?

Vou ser bem direto aqui. Brincadeiras à parte, em minha opinião ainda está por vir uma solução descente para persistência e recuperação de objetos em banco de dados relacionais. A integração entre o SQL Server e o .NET Framework é um passo nessa direção, mas ainda há um caminho a ser percorrido.

"