Conectar no banco de dados

Hoje em dia muitos desenvolvedores não sabem como funciona internamente a conexão com o banco de dados, ou não sabem como fazer para conectar com o banco de dados.

Se o banco de dados muda no meio do desenvolvimento, o desenvolvedor não sabe fazer a conexão ou a migração para o novo. Estou falando isso porque eu vi isso acontecer dentro da faculdade onde ministro aula.

O que o desenvolvedor precisa saber é que todo o banco de dados existe um “driver” para a conexão. Antigamente não existia muitos, mas hoje os “drivers” já chegam ou já são instalados quando o banco de dados ou a ferramenta são instalados.

Esse “driver” pode ser acessado utilizando uma linha de comando através da classe responsável de conexão da linguagem que você usa para desenvolvimento de software.

O PHP tem a sua classe para conexão, o C# tem a sua classe, o Java tem a sua classe, o ASP 3.0 tem a sua classe e assim vai. O que você precisa saber é, qual a classe de conexão com o banco de dados e qual a “string” de conexão deve ser utilizada. Lembrando que essa “string” precisa dos dados sempre, dados como: usuário, senha, servidor de banco de dados (geralmente nome ou ip), nome do banco de dados e outras informações como tipo de segurança ou “timeout”.

Qual a melhor maneira de fazer uma conexão com o banco de dados? 

Com a minha experiência de desenvolvimento e arquiteto de software, você concorda que a qualquer momento o tipo de banco de dados pode ser alterado? Por exemplo: o banco de dados era o MYSQL e foi alterado para SQL Server por algum motivo inexplicável.

Com essa mudança, o “driver” precisa ser alterado e além disso, a classe responsável pela conexão precisa ser alterada também.

A melhor forma para desenvolver um aplicativo que pode correr o risco de mudar de banco de dados a qualquer momento, é criar ou usar o modelo MVC. Não precisa ser o modelo já desenhado no mercado, pode ser um desenhado por você, por exemplo: basta criar a pasta DAO onde todas as classes são separadas de acordo com as tabelas do banco e responsáveis por fazer SELECT, INSERT, UPDATE e DELETE.

Exemplo prático: Tenho uma tabela de usuário onde armazeno todo o cadastro no meu site. Com isso, dentro da minha pasta DAO, eu tenho uma classe chamada UsuarioDAO onde todas as operações com o banco de dados são feitas apenas por essa classe; isso para a tabela usuário.

A única classe que acessa a tabela de usuário é a UsuarioDAO. Para gerenciar as regras de negócio que as vezes podem ter, é melhor criar uma classe responsável e que será a única que acessa a classe DAO. Isso evita que a sua interface acesse direto a classe DAO e faça regras de negócios pela interface. Para isso é bom criar uma pasta BRL. 

Continuando o nosso exemplo, é bom criar uma classe UsuarioBRL dentro da pasta BRL responsável por fazer toda a regra de negócio e acessar a classe UsuarioDAO. A interface chama a UsuarioBRL passando alguns parâmetros, que faz algum tratamento e depois chama a UsuarioDAO  para fazer o comando de INSERT no banco de dados.

Caso precise que algum dado seja buscado do banco e mostrado na interface, basta chamar um método da classe UsuarioBRL que por si só chama a classe UsuarioDAO que faz o comando SELECT e retorna os dados para a UsuarioBRL, verificando ou analisando alguma regra de negócio se houver e retorna para a interface.

Todo esse modelo falado anterior pode ser criado por você usando qualquer ferramenta de desenvolvimento como Visual Studio (qualquer versão), Eclipse, Visual Basic e outros do mercado.

Qual é a vantagem de usar MVC falado anteriormente?

A vantagem é que se o banco for alterado para outro tipo, basta mudar a classe que conecta o “driver” e pronto. Isso na teoria, pois muitas vezes, dependendo da forma que foi criado as classes, alguma coisinha precisa ser alterada também, mas é coisa leve.

O que vou mostrar aqui hoje são formas de conexão com banco de dados usando a linguagem C#.NET da Microsoft. 

Se você entendeu até aqui tudo o que foi falado, então não terá problemas em mudar o tipo de banco de dados no meio do desenvolvimento do aplicativo. A minha dica é que, procure usar as melhores práticas implantadas no mercado por que elas foram estudadas a fundo antes de serem jogadas no mundo de desenvolvimento de software.

Veja um exemplo real que aconteceu comigo: - uma aplicação “desktop” do meu trabalho estava utilizando o banco de dados SQL Server, funcionando perfeitamente. Surgiu um cliente que precisava dela porém não queria instalar o banco de dados na máquina local.

Eu pensei em fazer a conexão com um banco que não precisasse de instalação, como o SQLite, Access ou SQLCE (da Microsoft). Como a linguagem que estava utilizando era o C#, preferi utilizar o SQLCE cujo o “Framework.NET” já possui “driver” de conexão e classes específicas para executar comandos.

O único trabalho que tiver foi mudar as classes BRL e DAO e tudo ficou funcionando sem problema algum, foi instalado no cliente sem precisar instalar um banco de dados mais robusto.

Ah, acabei de me lembrar de uma coisa. Não gosto de utilizar aquelas coisas prontas da ferramenta de desenvolvimento, isso porque muitas vezes não é feito essa separação de classes e fica tudo dentro da mesma interface. 

Falo isso porque algumas ferramentas utilizam recursos para facilitar a vida do desenvolvedor que está aprendendo como clicar em três botões e a conexão com o banco é criada. Se você for olhar o código, a “string” de conexão fica dentro da página web, o comando também, as informações de banco ficam abertas para hackers e crackers e sua aplicação fica vulnerável.

Esse tipo de coisa pode ser legal para quem está aprendendo no primeiro momento, mas não é o ideal, principalmente porque se o banco de dados mudar para um outro, tudo terá que ser refeito, dando sem dúvida muito trabalho para o desenvolvedor.

Driver usando C#

Para conectar com um banco de dados Access da Microsoft, o “driver” de conexão pode ser feito assim. Listagem 1.1

string strConn = @"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\dados\Northwind.mdb; Password=123";

Listagem 1.1

Note que na listagem 1.1, o “driver” utilizado para conexão é o Microsoft.Jet.OLEDB 4.0. Esse “driver” internamente utiliza de mecanismos feitos a baixo nível para conectar no banco de dados informado no parâmetro Data Source. Essa informação você não sabe, porque os “frameworks” de hoje em dia abstrai isso do desenvolvedor.

Para conectar no banco de dados MySQL, a “string” já muda um pouco. Listagem 1.2.

string strConn = @"Server=localhost;Database=Cadastro;Uid=root;Pwd='numsey';Connect Timeout=30;"; 

Listagem 1.2

Note na listagem 1.2 que as informações passadas são mais detalhadas porque se trata de um servidor onde o banco está instalado. Se estiver na mesma máquina, basta informar o localhost. Porém o driver de conexão utilizado na ferramenta foi o MySql.Data.MySqlClient.

Para conectar no banco de dados SQL Server Express, a “string” muda um pouco referente aos outros. Listagem 1.3.

string strConn = @"Server = .\sqlexpress;Database = NorthWind; Integrated Security = SSPI;";

Listagem 1.3

Note que o parâmetro Integrated Security é passado, e com ele as informações dizendo que a integração precisa ser segura. Não passei usuário ou senha como nas “strings” anteriores, porém coloquei o item de segurança. Existem vários modelos de “strings” que podem ser utilizados.

Para conectar no banco Firebird a “string” muda também e o “driver” utilizado é o FireBirdCliet. Listagem 1.4

string strConn = @"DataSource=localhost; Database=C:\dados\EMPLOYEE.FDB; UserId=SYSDBA; Pwd=masterkey";

Listagem 1.4

Note que na listagem 1.4 a “string” é meio misturada como o Access e o MySql. Porém é feita para o FireBird.

Para conectar no banco SQLite, o “driver” utilizado é o System.Data.SQLite.dll. 

String strConn = @"Data Source=C:\dados\BDSQLite.db";

Listagem 1.5

A “string” é bem simples, basta informar o endereço do banco de dados e se houver senha basta coloca o parâmetro password.

Para conectar no banco de dados SQLCE, o “driver” utilizado é o System.Data.SqlServerCe. Listagem 1.6.

String strConn = @”DataSource=bd\audit.sdf”;

Listagem 1.6

Note que para o SQLCE, basta colocar o endereço do arquivo .sdf. Se houver senha, é bom colocar o parâmetro password também.

Bom, eu fico por aqui e dou oportunidade a você entrar em contato pelo meu site www.mauriciojunior.org caso queira tirar qualquer dúvida específica. Espero que tenha gostado do artigo. Abraços e obrigado caro(a) leitor(a).