Design Patterns - Tutorial/Exemplo de implementação VO,FAÇADE,DAO

Olá amigos,

Estou envolvido num projeto do qual trabalha com esses patterns tirando o DAO que já o conheço… precisava implentar esses outros 3 em conjunto.

Gostaria de ajuda dos amigos para implementar essa trinca de Patterns.

No Google existe um monte de informação mais não consegui um exeplo didadico aplicando essas 3.

PS: Uma pequena dúvida “FAÇADE” e “SESSION FAÇADE” são a mesma coisa?

Grato por qualquer ajuda.

Bem, que tal você começar explicando qual o seu problema pra agente ver se realmente vai precisar implementar essas coisas =P

Olá Mauricio, Bom dia,

não sei se fui claro… preciso trabalhar nesse ambiente de patterns que descrevi, so que não tenho conhecimento… estou estudando e lendo muiito.

precisava de um exemplo de implementação desses patterns com objetivo para estudo…

O projeto que participo toda a aplicação passa por essas camadas.

muito obrigado.

Não, Façade é como o próprio nome já diz uma fachada de métodos (altamente e bizarramente programação procedural) onde são disponibilizados serviços da camada de negócio. É uma fina camada que realiza alguns tratamentos de erros, controle de transações, etc. e que chama alguns outros métodos dos componentes de negócio para tal serviço ser efetuado corretamente.

O Session Façade é um padrão de projeto J2EE, oriundo da necessidade de unir os conceitos do Façade com a implementação de Sessions Beans no EJB.
Aí vc já tem um distribuição maior dos serviços.

Muito obrigado Fabrício Cozer Martins, ficou bem clara a explicação sobre o FAÇADE

Agora precisava de um exemplo ou artigo que implemente esses patterns em algum “estudo de caso/caso de uso”… preciso muito mesmo estudar esses patterns para dar continuidade em meu trabalho.

Muito obrigado aos amigos.

Explique porque você acha que o pattern facade é “altamente e bizarramente programação procedural”.

Ele é apenas uma fachada, não é uma forma de representar um objeto e sim procedures - chamadas a outros métodos - que se fosse colocado o corpo do método chamado não precisaria de orientação a objeto pra isso. É vinculada a um módulo do sistema e não a um objeto. Mas como o mundo caminha hoje pra arquitetura SOA, que tem uma certa característica procedural, você tem um um façade e disponibiliza isso para o cliente, você não oferece um objeto, e sim diversos métodos de negócios de diversos módulos. Enfim, sugiro dar uma olhada no http://domaindrivendesign.org/

Façades não têm tanto de procedural, elas servem para encapsular um subsistema. A partir do momento que você o faz este encapsulamento se torna um objeto.

Num acho procedural não…

concordo com o amigo acima.

Facade é um padrão! Server também para manter um nível de indireção a arquitetura de dominio de um sistema.
Deve ser utilizado para regras de négocio inteligáveis. Manter uma separação de interesses, entre regras de entrada e regras de dominio. blalalba.

Um bom motivo seria manter seu implementador longe dos seus DAOs! Ótimo motivo! rsr Sim!

Vou explicar sucintamente: hehe.

0{0{0}0{0}0}}0{ = Projeto ruim.

-{0}-{0}-{0}-{0}- = Projeto bom.

Entendeu? rsr

Não concordo, até porque pode-se utilizar Façade através de composição de objetos

Ele é apenas uma fachada, não é uma forma de representar um objeto e sim procedures - chamadas a outros métodos - que se fosse colocado o corpo do método chamado não precisaria de orientação a objeto pra isso. É vinculada a um módulo do sistema e não a um objeto. Mas como o mundo caminha hoje pra arquitetura SOA, que tem uma certa característica procedural, você tem um um façade e disponibiliza isso para o cliente, você não oferece um objeto, e sim diversos métodos de negócios de diversos módulos. Enfim, sugiro dar uma olhada no http://domaindrivendesign.org/
[/quote]

Se ainda for dúvida de alguém, segue link com uma aplicação de exemplo (Como solicitado pelo colega no inicio do tópico) e com diagrama de classe explicando como deve-se implementar facade.

http://www.pg.cefetpr.br/coinf/simone/patterns/facade.php

MaxWeber, ótimo artigo!