.NET - Camada de Acesso a dados - Boas Práticas (ADO .NET)

Uma Camada de Acesso a Dados (DAL-Data Access Layer) é composta por uma coleção de classes, interfaces e seus métodos e propriedades que são usadas para executar operações CRUD (criar, ler, atualizar e excluir).

Uma DAL encapsula o código que é usado para se conectar ao banco de dados e executar essas operações e funciona como um elo entre as entidades de negócios em seu aplicativo e a camada de armazenamento de dados. Você geralmente usa uma Data Access Layer para criar e preencher entidades de negócios com os dados do banco de dados e para a atualizar e armazenar de essas entidades na base de dados.

Na plataforma .NET temos muitas possibilidades de uso da ADO.NET; assim, é importante identificar padrões que resolvam os tipos de problemas mais comuns no dia a dia de forma a garantir produtividade e facilidade em futuras manutenções de código.

É importante notar que o que é sugerido como boa prática em termos de arquitetura de aplicação .NET coloca a aplicação dividida em camadas funcionais. A utilização de uma camada de dados entre a camada de regra de negócios encapsulando o ADO.NET garante a padronização do mesmo para as funcionalidades mais comuns do dia a dia, promovendo facilidades de manutenção, extensão e produtividade.

Mas apenas dividir sua aplicação em camadas não significa que você resolveu o problema, indica que você apenas começou trilhando o caminho certo. A utilização de boas práticas na implementação das camadas é que vai garantir que sua aplicação seja robusta e escalável.

Características de um Data Access Layer ( ADO .NET)

A camada de acesso de dados deve fornecer os seguintes recursos:

  1. Conexão com a base de dados
  2. Abrir e Fechar as conexões
  3. Dar suporte as operações CRUD
  4. Realizar o gerenciamento de transações
  5. Possuir a independência do provedor
  6. Realizar o gerenciamento da concorrência

Ao montar a estratégia para criar uma DAL devemos ter em mente os seguintes aspectos:

Crie todas as suas rotinas de acesso ao banco de dados como objetos genéricos, versáteis, ao invés de criar métodos do lado do cliente. A sua interface do usuário deve interagir com os componentes definidos na DAL (geralmente via camada de negócios) e não realizar operações diretamente com o banco de dados.
   
Se você quiser paginar os dados ou fornecer ao seu aplicativo esta funcionalidade pode utilizar um DataSet como método de dados desconectados, caso contrário, use um DataReader para a recuperação de dados. Para usuários XML isso se traduziria em um XmlReader, e StreamReader para arquivos de texto, ambos equivalentes a um DataReader para seus respectivos tipos de arquivo.
   
Use o provedor de dados gerenciado correto para o seu banco de dados, ex. System.Data.SqlClient para o SQL Server, System.Data.OLEDB para Access, System.Data.OracleClient para Oracle, etc
   
Use DataSets fortemente tipados, pois isso gera um melhor desempenho. Um dataset tipado gerado é basicamente uma classe early bound herdando da classe base DataSet, em oposição ao típico DataSet late bound. Fazendo assim você tem mais flexibilidade para lidar com os dados e o código para leitura dos dados será mais fácil visto que você pode acessar os campos e tabelas usando nomes customizados, em vez da forma convencional baseada em coleção.
   
Aproveite ao máximo o recurso do Caching, pois isso vai aumentar significativamente o desempenho e diminuir a interação de banco de dados persistente.
   
Utilize procedimentos armazenados com parâmetros com o método da Prepare() da classe Command, que armazena suas consultas para uso futuro do SQL Server. Ex: oCommand.Prepare()
   
Dê preferência a realizar chamadas em lote em uma única conexão ao vez de pequenas chamadas usando diversas conexões com banco de dados.
   
Aproveite o pool de conexão armazenando todas as suas seqüências de conexão no arquivo web.config. Além disso, você vai descobrir que seu aplicativo irá escalar muito melhor com qualquer aumento do tráfego de rede, duplicando, triplicando o valor padrão de Max Pool Size de 100 para 300, e aumentando o valor padrão do Connect Timeout de 10 segundos para 60.
   
Balanceie a utilização de Stored Procedures quanto a implementação de regras de negócio. Faça isso tendo em mente bom senso quanto ao real reaproveitamento de lógica e facilidade de manutenção. Muitas Stored Procedures podem ser afetadas, o que acabará resultando em dificuldades de manutenção;
   
Quando houver funcionalidades que sejam utilizadas por vários componentes, implemente-as em uma interface separada;
   
Quando há a necessidade de uso prolongado do objeto DataReader, aconselha-se considerar a opção de se utilizar Datasets, que são sempre desconectados (isso aumenta a escalabilidade). Quando possível, é interessante que a camada de dados exponha metadados (informações a respeito dos dados) tais como schema ou nomes de colunas: isso oferece maior flexibilidade para a camada de negócio. Os ganhos com flexibilidade têm um custo que é pago com degradação de desempenho ou até mesmo escalabilidade.
   
Evite a construção automática de um componente de acesso a dados para cada tabela física. Considere a possibilidade de escrever seus componentes de acesso a dados num nível de abstração e de normalização maior e mais próximo das necessidades imediatas da camada de negócio. É muito comum a criação de uma classe representando uma tabela que faz relacionamento entre duas tabelas. Neste caso, dê preferência por implementar métodos nas classes principais.
   
Habilite transações apenas quando for realmente imprescindível. Nunca marque todos os componentes de acesso a dados com “Require Transactions”. Marque tais componentes com “Supports Transactions”, adicionando o seguinte atributo:
[Transaction (TransactionOption.Supported)]
   
Ao fazer uso de níveis alternativos ao default de “isolation levels” em consultas, balanceie seu benefício quanto a performance e contenção, confrontando os requisitos de vazão e precisão dos dados. Em casos de alta vazão (throughput), a precisão dos dados pode ser prejudicada se forem utilizados níveis de isolamento menos rígidos;
   
Quando a aplicação contiver múltiplos componentes de acesso a dados, recomenda-se usar a camada testada e de alta performance Data Access Application Block em suas aplicações para gerenciar as conexões, executar comandos, fazer cache de parâmetros, etc
   
Finalmente, lembre-se de fechar, limpar e liberar todos os seus objetos de dados, não importa a quantidade.
   

 

João 9:39 Prosseguiu então Jesus: Eu vim a este mundo para juízo, a fim de que os que não veem vejam, e os que veem se tornem cegos.

 


 Veja os Destaques e novidades do SUPER DVD VB (sempre atualizado) : clique e confira !

Quer migrar para o VB .NET ?

Veja mais sistemas completos para a plataforma .NET no Super DVD .NET , confira...

Quer aprender C# ??

Chegou o Super DVD C# com exclusivo material de suporte e vídeo aulas com curso básico sobre C#
 

Referências:

José Carlos Macoratti