Persistência de dados
E ai galera, beleza?
Estou iniciando o desenvolvimento de um projeto orientado a objeto, e gostaria de saber qual o melhor jeito de fazer a persistencia dos dados, eu devo utilizar os componentes da palheta DataControl ou devo criar uma classe utilizando INSERT, UPDATE, SELECT e DELETE?
Se utilizar os componentes da palheta DataControl não estarei utilizando O.O. pois uma classe Empresa por exemplo de nada serviria, certo?
Por favor me digam qual o melhor jeito de fazer um sistema orientado a objeto em delphi...
desde já agradeço....abraço!!!
Estou iniciando o desenvolvimento de um projeto orientado a objeto, e gostaria de saber qual o melhor jeito de fazer a persistencia dos dados, eu devo utilizar os componentes da palheta DataControl ou devo criar uma classe utilizando INSERT, UPDATE, SELECT e DELETE?
Se utilizar os componentes da palheta DataControl não estarei utilizando O.O. pois uma classe Empresa por exemplo de nada serviria, certo?
Por favor me digam qual o melhor jeito de fazer um sistema orientado a objeto em delphi...
desde já agradeço....abraço!!!
Itepi
Curtidas 0
Respostas
Carlosfim
09/03/2009
itepi,
Vou fazer um resumo rápido do que usamos aqui:
1- Um modelo de domínio, com classes do domínio da aplicação: TCliente, TNotaFiscal, TItemNota, ...
Estes objetos são objetos simples, sem uso de nenhuma tecnologia (O pessoal do JAVA chamaria estes objetos de POJO). Estes podem conter alguma lógica, desde que esta faça parte do domínio do problema, e não do domínio da solução.
2- Uma camada de serviços, que nada mais é do que uma classe controladora, para cada módulo. No cadastro de clientes, por exemplo, tenho um ´POJO´ TCliente, que armazena os dados do cliente, e uma classe ClienteController, que é responsável, entre outras coisas, por:
- Controlar (controller) o fluxo da aplicação, ou seja, controlar as interações entre UI, POJO, DB, ..
- Regras de negócio inerentes ao domínio da solução.
- Controle de acesso (permissões do usuário), comunicação com outros módulos do sistema, etc.
3- Uma camada DAO, que é quem se comunica com o banco de dados. Para cada ´POJO´ existe uma DAO correspondente. Então, para a classe TCliente, existe uma classe chamada TClienteDAO, com métodos do tipo:
- AdicionaCliente(Cliente: TCliente);
- AtualizaCliente(Cliente: TCliente);
- ExcluiCliente(Cliente: TCliente);
- RecuperaCliente(ID: integer): TCliente;
- Etc...
Cada um desses métodos vai transformar os dados de TCliente em seus respectivos INSERTS, UPDATES, DELETES, ...
4- Classes UI, que são formulários normais do Delphi, com a diferença que NÃO usamos nenhum controle DataAware (com exceção dos DBGrids, para apresentar a lista de todos os Clientes - aqui é bobagem carregar todos os clientes em objetos e montar um StringGrid, por exemplo).
5- Claro que existem outros detalhes menores, mas de cara esta é a estrutura que estou utilizando hoje.
PERGUNTAS:
1- Dá trabalho? Sim, mas também dá muita flexibilidade.
2- Preciso fazer tudo na mão? Não. Existem frameworks que vão ajudar você a fazer a persistência, por exemplo;
3- Qual a vantagem de fazer isso tudo?
- Flexibilidade 1: Como já citado, as partes ficam mais separadas, o que facilita muitas coisas. Imagina se eu resolvo mudar o nome da tabela de clientes, de TabClientes para TabCadastroClientes? O único lugar onde eu iria mecher no código seria na classe TClienteDAO, mais em lugar nenhum, com a segurança de que isso não vai quebrar o meu código porque eu esqueci de atualizar aquele procedimento que só meia dúzia de usuários usam.
- Flexibilidade 2: fica muito mais fácil dividir meu sistema em módulos, fisicamente e lógicamente falando;
- Flexibilidade 3: mais fácil de gerenciar a equipe de desenvolvimento, sendo que posso botar cada programador para trabalhar em uma parte do sistema, sem que isso quebre o código do outro (é claro, se os módulos (lógicos) estiverem bem estruturados, com interfaces bem definidas)
- Facilidade de testar/debugar 1: é bem mais fácil achar os erros. Exemplo: se não tá gravando direito no banco, é bem provável que tenha alguma classe DAO que não está fazendo seu trabalho como deveria.
- Facilidade de testar/debugar 2: usando objetos é bem mais fácil testar o código. Posso até fazer testes automatizados...
Bom, poderia ficar aqui citando várias vantagens, mas como você está interessado em programar OO, acho que já está convencido das vantagens deste modelo (OO, não o meu: este é só uma sugestão).
Espero ter ajudado,
Vou fazer um resumo rápido do que usamos aqui:
1- Um modelo de domínio, com classes do domínio da aplicação: TCliente, TNotaFiscal, TItemNota, ...
Estes objetos são objetos simples, sem uso de nenhuma tecnologia (O pessoal do JAVA chamaria estes objetos de POJO). Estes podem conter alguma lógica, desde que esta faça parte do domínio do problema, e não do domínio da solução.
2- Uma camada de serviços, que nada mais é do que uma classe controladora, para cada módulo. No cadastro de clientes, por exemplo, tenho um ´POJO´ TCliente, que armazena os dados do cliente, e uma classe ClienteController, que é responsável, entre outras coisas, por:
- Controlar (controller) o fluxo da aplicação, ou seja, controlar as interações entre UI, POJO, DB, ..
- Regras de negócio inerentes ao domínio da solução.
- Controle de acesso (permissões do usuário), comunicação com outros módulos do sistema, etc.
3- Uma camada DAO, que é quem se comunica com o banco de dados. Para cada ´POJO´ existe uma DAO correspondente. Então, para a classe TCliente, existe uma classe chamada TClienteDAO, com métodos do tipo:
- AdicionaCliente(Cliente: TCliente);
- AtualizaCliente(Cliente: TCliente);
- ExcluiCliente(Cliente: TCliente);
- RecuperaCliente(ID: integer): TCliente;
- Etc...
Cada um desses métodos vai transformar os dados de TCliente em seus respectivos INSERTS, UPDATES, DELETES, ...
4- Classes UI, que são formulários normais do Delphi, com a diferença que NÃO usamos nenhum controle DataAware (com exceção dos DBGrids, para apresentar a lista de todos os Clientes - aqui é bobagem carregar todos os clientes em objetos e montar um StringGrid, por exemplo).
5- Claro que existem outros detalhes menores, mas de cara esta é a estrutura que estou utilizando hoje.
PERGUNTAS:
1- Dá trabalho? Sim, mas também dá muita flexibilidade.
2- Preciso fazer tudo na mão? Não. Existem frameworks que vão ajudar você a fazer a persistência, por exemplo;
3- Qual a vantagem de fazer isso tudo?
- Flexibilidade 1: Como já citado, as partes ficam mais separadas, o que facilita muitas coisas. Imagina se eu resolvo mudar o nome da tabela de clientes, de TabClientes para TabCadastroClientes? O único lugar onde eu iria mecher no código seria na classe TClienteDAO, mais em lugar nenhum, com a segurança de que isso não vai quebrar o meu código porque eu esqueci de atualizar aquele procedimento que só meia dúzia de usuários usam.
- Flexibilidade 2: fica muito mais fácil dividir meu sistema em módulos, fisicamente e lógicamente falando;
- Flexibilidade 3: mais fácil de gerenciar a equipe de desenvolvimento, sendo que posso botar cada programador para trabalhar em uma parte do sistema, sem que isso quebre o código do outro (é claro, se os módulos (lógicos) estiverem bem estruturados, com interfaces bem definidas)
- Facilidade de testar/debugar 1: é bem mais fácil achar os erros. Exemplo: se não tá gravando direito no banco, é bem provável que tenha alguma classe DAO que não está fazendo seu trabalho como deveria.
- Facilidade de testar/debugar 2: usando objetos é bem mais fácil testar o código. Posso até fazer testes automatizados...
Bom, poderia ficar aqui citando várias vantagens, mas como você está interessado em programar OO, acho que já está convencido das vantagens deste modelo (OO, não o meu: este é só uma sugestão).
Espero ter ajudado,
GOSTEI 0
Itepi
09/03/2009
CarlosFim, muito obrigado pela sua resposta, realmente foi bem esclarecedora....
Realmente tenho visto inumeras vantagens da programação OO em cima da programação estruturada, antes de entrar na faculdade programava somente estruturalmente, depois que aprendi a OO comecei a ver os meus sistemas que já tinha visto com outros olhos, vendo soluções mais fáceis e melhores.
Obrigado cara, abraço!
Realmente tenho visto inumeras vantagens da programação OO em cima da programação estruturada, antes de entrar na faculdade programava somente estruturalmente, depois que aprendi a OO comecei a ver os meus sistemas que já tinha visto com outros olhos, vendo soluções mais fáceis e melhores.
Obrigado cara, abraço!
GOSTEI 0
Diegotiemann
09/03/2009
Ressuscitando este tópico.
Carlos, bem esclarecedora sua resposta, mas pra mim continua uma dúvida.
Qual a melhor maneira de fazer a integração da da ´POJO´ com a ´UI´?
Exemplo, imagine que você tem uma classe que ´POJO´ que tem diversas validações e conforme o usuário vai preenchendo os campos de cima pra baixo são feitas validações, são exibidos/ocultados campos no formulário.
Nesse caso é melhor criar o ´POJO´ no create do formulário ´UI´?
Resumindo o meu sistema precisa fazer as validações conforme o usuário preenche, não basta validar somente quando ele clica em salvar.
Carlos, bem esclarecedora sua resposta, mas pra mim continua uma dúvida.
Qual a melhor maneira de fazer a integração da da ´POJO´ com a ´UI´?
Exemplo, imagine que você tem uma classe que ´POJO´ que tem diversas validações e conforme o usuário vai preenchendo os campos de cima pra baixo são feitas validações, são exibidos/ocultados campos no formulário.
Nesse caso é melhor criar o ´POJO´ no create do formulário ´UI´?
Resumindo o meu sistema precisa fazer as validações conforme o usuário preenche, não basta validar somente quando ele clica em salvar.
GOSTEI 0