Não sei se são propriamente dicas, mas acho que vale a pena ler e, por favor me contestem para eu poder aprender.
Notei aqui que a grande maioria utiliza sistemas de duas camadas ou client/server, ou seja, para cada pc acessando o sistema, haverá no mínimo uma conexão ao banco de dados; com isto a aplicação fica repleta de componentes sql como databases, tables e querys.
Vale lembrar que em muitas aplicações client/server não é possível conectar-se ao banco de dados via internet.
Dica n.1:
Esqueçam os componentes TTable e utilizem TQuery.
Com isto vocês serão forçados a aprender e utilizar comandos sql.
Dica n.2:
Esqueçam o TDataModule e não coloquem componentes sql em tempo de projeto.
Crie-os e libere-os conforme a necessidade em tempo de execução. Isto dará mais noção à orientação a objetos que é realmente como o Delphi trabalha e otimizará recursos de memória.
Dica n.3:
Não deixem os parâmetros de conexão ao banco de dados fixos dentro da aplicação e sim externos como no registro do Windows por exemplo.
Dica n.4:
Criem uma classe de conexão numa unit separada com funções que retornam objetos de conexão e objetos de acesso aos dados; por ex:
BDE retorna Tdatabase e Tquery
DBExpress retorna Tsqlconnection e Tsqlquery ou TsqlclientDataSet
InterbaseExpress retorna Tibdatabase e Tibquery ou TibclientDataSet
Etc...
Retornem para a aplicação a classe ancestral e, se houverem métodos próprios da classe filha, utilizem o Cast.
No caso de conexão retornem TCustomConnection.
No caso de acesso aos dados, retornem TDataset.
Pois todas elas derivam destas classes.
Com isto a aplicação fica mais enxuta e não implicará em grandes mudanças no caso de mudança de banco de dados ou meio de acesso.
Lembro aqui que perdí ± 3 meses com testes em conexão ADO(Activex Data Object) e desistí porque como este tipo de conexão utiliza automação OLE Variant, a performance caiu consideravelmente em relação ao BDE.
Dica n.5:
Após serem efetuadas as 4 etapas acima, o próximo passo é criar um servidor de banco de dados para desenvolvimento de sistemas em 3 camadas, onde a aplicação cliente ficará livre dos componentes sql e TDBs que serão substituidos por componentes Socket e TCP/IP para conexão com o servidor.
Com isto não importa onde o banco esteja, pode ser na mesma máquina, numa intranet, internet, ou qualquer outra rede que entenda o protocolo TCP/IP.
Minha próxima dica seria como criar um objeto de manipulação e transporte de dados para comunicação entre cliente e servidor, mas não sei se seria muito útil escrevê-la neste momento.
Bom, espero que tenha sido de alguma serventia para alguém e também espero ser contestado no fórum para sempre aprender e corrigir meus erros.
Pergunta
s3c
Banco de Dados.
Como chegar às 3 camadas.
Olá colegas deste fórum.
Não sei se são propriamente dicas, mas acho que vale a pena ler e, por favor me contestem para eu poder aprender.
Notei aqui que a grande maioria utiliza sistemas de duas camadas ou client/server, ou seja, para cada pc acessando o sistema, haverá no mínimo uma conexão ao banco de dados; com isto a aplicação fica repleta de componentes sql como databases, tables e querys.
Vale lembrar que em muitas aplicações client/server não é possível conectar-se ao banco de dados via internet.
Dica n.1:
Esqueçam os componentes TTable e utilizem TQuery.
Com isto vocês serão forçados a aprender e utilizar comandos sql.
Dica n.2:
Esqueçam o TDataModule e não coloquem componentes sql em tempo de projeto.
Crie-os e libere-os conforme a necessidade em tempo de execução. Isto dará mais noção à orientação a objetos que é realmente como o Delphi trabalha e otimizará recursos de memória.
Dica n.3:
Não deixem os parâmetros de conexão ao banco de dados fixos dentro da aplicação e sim externos como no registro do Windows por exemplo.
Dica n.4:
Criem uma classe de conexão numa unit separada com funções que retornam objetos de conexão e objetos de acesso aos dados; por ex:
BDE retorna Tdatabase e Tquery
DBExpress retorna Tsqlconnection e Tsqlquery ou TsqlclientDataSet
InterbaseExpress retorna Tibdatabase e Tibquery ou TibclientDataSet
Etc...
Retornem para a aplicação a classe ancestral e, se houverem métodos próprios da classe filha, utilizem o Cast.
No caso de conexão retornem TCustomConnection.
No caso de acesso aos dados, retornem TDataset.
Pois todas elas derivam destas classes.
Com isto a aplicação fica mais enxuta e não implicará em grandes mudanças no caso de mudança de banco de dados ou meio de acesso.
Lembro aqui que perdí ± 3 meses com testes em conexão ADO(Activex Data Object) e desistí porque como este tipo de conexão utiliza automação OLE Variant, a performance caiu consideravelmente em relação ao BDE.
Dica n.5:
Após serem efetuadas as 4 etapas acima, o próximo passo é criar um servidor de banco de dados para desenvolvimento de sistemas em 3 camadas, onde a aplicação cliente ficará livre dos componentes sql e TDBs que serão substituidos por componentes Socket e TCP/IP para conexão com o servidor.
Com isto não importa onde o banco esteja, pode ser na mesma máquina, numa intranet, internet, ou qualquer outra rede que entenda o protocolo TCP/IP.
Minha próxima dica seria como criar um objeto de manipulação e transporte de dados para comunicação entre cliente e servidor, mas não sei se seria muito útil escrevê-la neste momento.
Bom, espero que tenha sido de alguma serventia para alguém e também espero ser contestado no fórum para sempre aprender e corrigir meus erros.
Obrigado a todos!!!
Link para o comentário
Compartilhar em outros sites
0 respostass a esta questão
Posts Recomendados
Participe da discussão
Você pode postar agora e se registrar depois. Se você já tem uma conta, acesse agora para postar com sua conta.