e=Verdana size=2>

Clique aqui para ler todos os artigos desta edição
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
· 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
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.