Fechando esta sequência de artigos sobre a nova versão da Classe de Conexão, cheguei a algumas conclusões, sendo algumas meio óbvias, algumas melhorias a fazer, entre outras.

A mais óbvia é a capacidade de reaproveitamento de código que podemos obter seguindo este modelo de desenvolvimento, centralizando tudo o que for relacionado às chamadas de Providers na Classe de Conexão e centralizando as operações de persistência em uma classe DAL genérica.

Como pudemos ver nesta e em oportunidades anteriores, não usamos NENHUMA declaração de provider específico de banco de dados: é bem dizer o mesmo código para N bancos de dados; a diferença está na sintaxe dos comandos SQL em si.

Nestas mesmas oportunidades anteriores, vimos que as operações básicas das classes de cadastro são feitas da mesma maneira, e ao centralizar estas operações em uma classe genérica tivemos um aproveitamento monstruoso: Bastou construir a parte VO de uma classe e já estava tudo funcionando.

Economizamos código também na codificação (no code-behind) da interface de usuário. Um dos “trabalhos braçais” mais chatos que existem é exatamente a atribuição dos valores nos componentes da UI. Principalmente se tiver dezenas de campos a serem preenchidos.

De quebra, ainda pude aprender a usar um pouco do conceito de Reflection do .NET.

Como, já dizia o ditado, nem tudo são flores: Temos também a parte chata, de que temos que redobrar a atenção ao seguir algumas convenções. Nas primeiras vezes, é um pouco chato, mas vamos nos acostumando a isso e o resto vai de boa.

Embora facilite bastante, seguir as convenções ao pé-da-letra pode restringir um pouco o uso da Classe de Conexao. Nada que uma POG bem feita não resolva, mas o intuito não é apelar para este lado.

Pensando em algumas restrições que pude perceber ao longo da existência (e da adoção onde eu trabalho) da Classe de Conexão, há melhorias a serem feitas, com certeza.

Uma destas restrições é na parte de transações. Como a Classe de Conexão foi projetada pensando-se em uma aplicação Web, onde ela se conecta ao banco, faz o que tem que fazer, e desconecta-se, e quis evitar ao máximo possível a declaração de providers fora da Classe Conexao, tive que criar uma coleção e um método para executar instruções SQL em lote, em uma única transação.

Só que isso trouxe a limitação em si: Somente poderei executar instruções que não me retornem resultset dentro da coleção BatchSQLItens.

Só que também existem horas que eu preciso fazer um Select dentro da mesma sessão em que a transação é executada: o método ExecuteBatchSQL quando termina a execução ele já encerra a sessão. Desta forma não é possível fazer isso.

Já deu para saber uma deficiência a melhorar: Fazer um controle de transações que não dependa da coleção BatchSQLItens :-)

Outras melhorias são acrescentar o suporte para Windows Forms, e quem sabe, aplicações Mobile.

Mas… essa Classe de Conexão está me ajudando bastante em meus projetos, tenho tido um ótimo ganho de tempo com ela e esse jeito de desenvolver.

Um abraço!