Arquivo Discussoes de Programacao e Tecnologia 
Galera alguem poderia me explicar como funciona a arquitetura três camandas, sendo que o principio dela e deixar 1 independente da outra.
é nesse ponto que eu não intendo, como eu posso por exemplo deixar minha regra de negocio separada do banco de dados se eu vou precisar acessar essa outra camanda por meio de algum objeto.
desde ja eu agradeço
Então…a idéia é reduzir o acoplamento, realmente, vc terá de fazer chamadas “entre as camadas”, mas vc tem reduzir ao máximo essas chamadas… expliquei???
não necessariamente reduzir, exite o facade é um design pattern para resolver as multichamdas entre as camadas
facade
http://www.home.earthlink.net/~huston2/dp/facade.html
exemplo
http://www.home.earthlink.net/~huston2/dp/FacadeDemosJava
Eu creio que o importante é deixar as classes de regra de negócio sem depender da implementação das classes do banco. Tem um principio de designer OO que diz que vc deve programar para interfaces. Essa é a chave. Sua regra de negócio pode conhecer a interface do DAO (da camada de persistência) mas não precisa estar acoplada a implentação do DAO.
Essa parte é meio díficilo de entender, dá uma olhada em padrões de projeto que fica fácil.
espero ter ajudado.
ahueahueahueha
mas não está fora do escopo
essa “nuvem” ai é a confusão que o facade resolve
aheuahuehauehau
Tipo então eu terei algo assim
camada de banco de dados
camada de comunicação (banco de dados && regras de negocio)
camada de regras de negocio
camada de comunicação (regra de negocio && interface grafica)
camada de interface grafica
no meu ver para deixar uma camanda independente da outra seria essa, corrijão se meu raciocinio tiver errado.
uma coisa são conceitos outra é a prática…
quando vc ve isso funcionando vc realmente consegue assimilas caso contrario vai ficar sempre com a impressão de dúvida sobre o assunto…
“não existe” camada de transição, vc não modelaria isso explicitamente como vc ta fazendo ai porem o seu raciocinio não está errado
tendeu
Tipo então não deveria criar aquela camanda de comunição.
Por que é meio complicado de analizar algo que seja totalemente independente, sendo que ele precisão ser comunicar de alguma maneira.
É melhor separar por camadas ñ só pelas regras padrões de projeto, mas tb pele legilibilidade do seu sistema.
Na implementação essas camadas viram muitas classes que, iram se comunicar por chamadas.
Seria assim com 3 camadas:
Camada de Apresentação
Camada de Regras de Negócio
Camada de Persistência
não seria:
Camada de Apresentação
Camada de modelo
Camada de controle
O q faria sua camada de controle e modelo?
Quando eu especifiquei como camada de Regras de Négocio e persistência. Quis dizer q é onde seria a implementada as regras de negócio do sistema e a camada q comunica com o Banco de Dados persistindo os objetos do sistema, respectivamente.
O q faria sua camada de controle?
Quando eu especifiquei como camada de persistência. Quis dizer q é a camada q comunica com o Banco de Dados persistindo os objetos do sistema.
controle faria a comunicação entre a aparesentção e o modelo, num sei, mas não faria uma camada de persistência, mas sim, na camada de modelo haveriam umas classes “DAO” que fariam a pessistência.
isso é uma abordagem conceitual, ou seja bem genérica. Como se organiza as classes, é particular
isso é uma abordagem conceitual, ou seja bem genérica. Como se organiza as classes, é particular
É particular? sei lá, acho que sim… até subjetivo, talvez, mas estou meio confuso, explicar melhor o que vc quiz dizer??
Entã ficaria assim meu projeto
camada do Usuario (Interface Grafica), usando eventos separado dos objetos visuais ele acessaria a camanda de negocio, que por sua vez devolvera o resultado para evento que modificara a interface do usuario. seria isso???
MVC (model view control)
M- modelo, negócio, camada onde fica os seus componenetes do negocio
V- tela, interface, camada responsavel por interagir com o usuario
C- controle, camada responsavel por coordenar o funcionamento
ex.: Cadastrar Cleinte
a interface recebe os dados digitados
o objeto de camada de negocio valida os dados
a camada de controle persiste os dados
por alta é isso ai
Em primeiro lugar gostaria de agradecer a colaboração de todos com minha santa ignorancia.
Bom então pra min me comunicar com interface usuario com a camanda de negocio eu uso eventos certo?
agora pra min me comunicar com a camada de persistencia qual seria a melor abordagem.
Olá,
Me aprece que vocês estão confundindo camadas e MVC. Algum material com referências sobre o assunto:
http://www.fragmental.com.br/wiki/index.php?title=Arquitetura_de_Camadas_em_Java_EE
Tem razão :lol:, mas agora as coisas estão de volta no se devido lugar.
o papo foi bem esclarecedor
achei um link q resumi tudo isso:
http://www.macoratti.net/vbn_mvc.htm
a parte de camada visual e camada de negocio fico mais ou menos claro como implementar, e a camada de negocio e a camada de persistencia?
a parte de camada visual e camada de negocio fico mais ou menos claro como implementar, e a camada de negocio e a camada de persistencia?
Acho que a camada de negócio e de persistência são a mesma, vc chamada os dados, aplica as regras de négocio e salva de novo, não vejo pq separar isso, o que vc acha? Isso é camada de modelo (persitência + regras de negócio), não é?
o seu clienteVO (que é um javabean comum) e o seu clienteDAO(que é a classe de persistencia) podem ate ficar na mesma camada de negocio porem vc tem que ficar ligado e no funcionamento …
quem aciona essa classe tem que estar no controle sacou … assim como que faz a parte de interagir o cadastro do cliente tem que estar na view
a arrumação é importante sim porem o funcionamento e qe deve se ater
Acho que a camada de negócio e de persistência são a mesma, vc chamada os dados, aplica as regras de négocio e salva de novo, não vejo pq separar isso, o que vc acha? Isso é camada de modelo (persitência + regras de negócio), não é?
Camadas reúnem classes (ou componentes, ou o que quer que seja) com responsabilidade semelhantes. Existem classes cuja responsabilidade é modelar o negócio e existem classes cuja responsabilidade é controlar e gerenciar o acesso a dados.
Normalmente não se msituram estas classes porque para o negócio do seu cliente onde e como os dados são armazenados é irrevlevante. Isso indica alta coesão, uma coisa boa.
Se os grupos de classes possuem responsabilidades diferentes eles são candidatos a ficarem em Camadas diferentes, já que Camadas são agrupamentos de classes com responsabilidades semelhantes.
Agora, falando de MVC e Camadas, vou colar algo que coloquei em outro tópico:
humm, muito interessante…
