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.
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.
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 vezeal.
Eu pensei em fazer a conexão com um banco que nãos 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.
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
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\MacorattiSQLite.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.
OBS: Caso você esteja trabalhando com algum SGBD
diferente dos citados acima, você pode estar consultando o site abaixo para saber quais as informações de conexão você deve especificar para conectar a sua aplicação ao banco de dados desejado.
Strings de Conexão
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).
This article was originally written by:
Maurício Júnior
MCP, MCAD, MVP Microsoft
www.mauriciojunior.org
blog.mauriciojunior.org
www.ecode10.com