Ir para conteúdo

POWERED BY:

Arquivado

Este tópico foi arquivado e está fechado para novas respostas.

Caduzera

Orientado a Objeto (Praticas)

Recommended Posts

Salve galera, como estão?

 

Seguinte estou querendo aprender POO com Delphi 2006 e peguei um sistema relativamente pequeno que tenho e vou tentar refazê-lo com POO e logo de início já me deparei com uma dúvida sobre qual prática é melhor.

 

Vamos lá, pelo que sei a programação POO se dá um camadas OK? De modo simples podemos dizer que existêm as seguintes camadas:

- Persistência

- Negócio

- Interface

 

Porém, não sei bem como entende esta divisão em uma aplicação. Exemplo:

 

Interface: A camada de interface ao meu ver é simplismente a TELA que estou montando OK?

 

Negócios: Para mim, seria a classe em si, isto é, a Unit que usu para montar a classe e seus métodos.

 

Persistência: Essa camada é que me deixa meu confuso. Vi um exemplo de um cara que cria um DM e coloca lá todos os métodos de GRAVAR, ALTERAR, EXCLUIR de todas as classes. É o certo? Como fazer?

 

Me desculpe se o post é meio grande mas peço a ajuda e até a recomendação de materias na NET e IMPRESSOS ...

 

Abs.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Olá Caduzera, tudo bem?

 

Bem, alguem pode me corrigir, mas trabalhar com POO e camadas são suas coisas distintas. A programação orientada a objetos consiste na estruturação de classes, para que objetos sejam estanciados, e é neles que tudo acontece!

 

Quanto as camadas podem ser divididas de varias maneiras, não necessáriamente 3 camadas, vai de acordo com a necessidade do seu projeto. Eu trabalhei com 3 camadas no delphi 6, utilizando MIDAS. Eram divididas em:

 

INTERFACE : Que é realmente o que você disse, telas e mais telas, e apenas isso. Nada de regras de negocio, no maximo validações dos campos.

 

NEGOCIO : Onde toda regra acontece, onde existe o acesso ao banco de dados para gravação, alteração, enfim, todo "trabalho" é realizando aqui.

 

FISICA: é o banco de dados.

 

Vai de voce estruturar e bolar uma ideia legal para seu projeto.

 

Espero ter ajudado!

=)

Compartilhar este post


Link para o post
Compartilhar em outros sites

Obrigado pela explicação Laura ... !!

 

Hoje eu trabalho com aplicações Client/Server no Delphi com DataSnap neste mesmo formato que você mencionou !!

 

Estou tentando fazer a junção deste modelo com orientação a objeto. Estou procurando parâmetros de como montar a estrutura da aplicação!!

 

Não sei se consegui ser claro, mas minhas dúvidas são: Nas telas de cadastro (por exemplo) devo colocar os DataSet's dela na tela? Crio um DM?

 

Essas coisas ...

Compartilhar este post


Link para o post
Compartilhar em outros sites

Gosto de criar regras de organização para meus projetos, por exemplo:

* Componentes de "banco de dados" sempre ficam de DM, nunca nos formulários. Ou seja, para cada tela de cadastro eu acabo tendo um DM.

* Na aplicação cliente não há contato diretamente com o banco, são utilizados os "clientDataSet". Apenas a aplicação servidor que conhece o banco de dados e as regras de negocio. Disponibilizo serviços na minha aplicação servidor, que eu utilizo na cliente para varias coisas.

 

A aplicação de POO (pra mim) acontece apenas no servidor, que é onde eu efetivamente realizo todas as manipulações e processos do sistema. É lá que eu crio os objetos e manipulo tudo.

 

Espero estar ajudando! E se alguem discordar das minhas dicas, adoraria outra opnião!

=)

Compartilhar este post


Link para o post
Compartilhar em outros sites

Entendo que a forma como o delphi oferece a codificação não incentiva muito a criação de classes e sim o reaproveitamento de classes já existentes, mas, tipo, acho que dá para colocar mais POO na sua vida

Compartilhar este post


Link para o post
Compartilhar em outros sites

×

Informação importante

Ao usar o fórum, você concorda com nossos Termos e condições.