Artigo .net Magazine 57 - MultiBancos em ASP.NET

Web – Boa Idéia – Boas Práticas

MultiBancos em ASP.NET

Aplicação Web em camadas para acessar bancos Firebird e SQLServer em ASP.NET

Aplicações que acessam mais de um tipo de banco de dados, estão se tornando cada vez mais comuns e apresentam para muitos desenvolvedores um desafio. Muitas vezes a definição de uma solução tem como uma das regras a possibilidade de acessar tipos de bancos de dados diversos e com isso estar preparada para uma possível futura mudança.

Neste artigo vamos montar uma pequena aplicação ASP.NET estruturada em camadas que através da configuração de parâmetros externos à aplicação nos permitirá acessar um banco de dados SQLServer ou Firebird. Em artigos anteriores mostrei como desenvolver uma aplicação ASP.NET em camadas para acessar via código, banco de dados SQLServer (.NET Magazine 54 ) e Firebird (.NET Magazine 55). Naqueles artigos usamos a camada de negócios e dados em uma única DLL, e comentei que isso seria válido se sempre fosse usado o mesmo banco de dados. Comentei ainda que uma aplicação, que acesse mais de um banco de dados, precisará separar as camadas de negócios da camada de dados em DLLs diferentes, pois somente desse modo a aplicação terá a flexibilidade necessária para atingir este objetivo.

Agora chegou o momento de mostrar como podemos fazer isso, usando como base a mesma técnica de programação dos artigos anteriores. Vamos usar o nossa página ASP.NET como interface com o usuário (UI), criar uma Class Library (DLL) contendo as regras do negócio e uma outra Class Library(DLL) contendo a camada de dados na forma de um componente independente com inteligência para interação com o banco de dados.  Os parâmetros da aplicação, que contêm a string de conexão com cada banco estarão em um arquivo XML.

Camada de acesso a dados (Data Layer) – A Teoria

A camada de dados deve possuir inteligência para resolver as solicitações de recuperação ou gravação de dados da nossa aplicação. O modo mais fácil de fazer isso é construir uma classe que possua as habilidades do ADO.NET divididas em métodos que executam trabalhos específicos. Na quase totalidade de aplicações do mundo real, quando fazemos acesso a um banco de dados temos basicamente a necessidade de executar uma query SQL no banco e esta nos retornar os dados encontrados, ou, executar uma query que não volte dados, mas faça alguma ação no banco, como um INSERT por exemplo. Com isso em mente, vamos construir a nossa classe de acesso a dados contendo alguns métodos que executarão uma tarefa específica e nos retornar, se for o caso, o resultado. Por exemplo, na nossa classe vamos criar um método que executa um SELECT no banco e retorna o resultado na forma de um DataTable do ADO.NET. Poderíamos construir ainda outro método que nos retornaria o valor de um campo de uma tabela, usando o método ExecuteEscalar do objeto command, pois isso seria útil em muitas situações.

Você deve estar se perguntando: “Como vou declarar a variável que guardará o objeto connection da classe correta? E a variável para o DataAdapter?”. Isso é um problema, pois o nosso método precisa tipar a variável como da classe correta para o tipo de banco desejado, e como podemos ora estar usando um banco, e ora outro, temos de ter um meio de resolver isso. A resposta está nas características de um driver DataProvider do .NET . As classes que fazem parte de um DataProvider no .NET estão implementadas com base em interfaces. Por exemplo, as classes de conexão SQLConnection ou FBConnection são baseadas na interface IDBConnection. O fato de estas classes estarem vinculadas a interfaces comuns permite que os componentes de uma aplicação façam referência apenas às interfaces e não às classes. Com isso os componentes podem utilizar uma classe connection sem saber exatamente a que DataProvider pertence, apenas utilizando as definições de métodos existentes na interface. Mas tenha em mente que no momento de criação da instância das classes é necessário que a classe em si seja conhecida. A solução para isso é nossa classe de Dados possuir métodos específicos para a criação de uma Connection, um DataAdapter e um Command. Esses métodos devem receber um parâmetro, indicando para qual tipo de banco a classe deverá ser criada, criar a instância da classe correta e retornar a interface IDB do tipo correspondente. Pode parecer meio confuso agora, mas quando você analisar o código verá que é mais simples do que parece. Então vamos lá? Está na hora de começarmos a criar a nossa classe.

Preparando e organizando o ambiente para este artigo

Para uma melhor organização vamos criar uma estrutura de pastas onde guardaremos o código-fonte do artigo e suas ferramentas. Abra o " [...] continue lendo...