Definição pacote DAO e pacote Facade

Na verdade isso são Design Patterns, os quais convencionalmente separamos em pacotes com os nomes dos mesmo :lol:

Da um procurada no Google que tem muita coisa sobre:

http://www.google.com.br/search?q=Design+patterns

http://java.sun.com/blueprints/patterns/catalog.html

O DAO formar um pacote até que vai, mas o Façade ? convenhamos que não faz muito sentido uma classe ser um pacote ainda mais quando ela depende de outras.

Ambos são design patterns , mas pacotes não devem ser formados em torno de design patterns e sim em torno de funcionalidades.

O DAO formar um pacote até que vai, mas o Façade ? convenhamos que não faz muito sentido uma classe ser um pacote ainda mais quando ela depende de outras.

Ambos são design patterns , mas pacotes não devem ser formados em torno de design patterns e sim em torno de funcionalidades.

Vc quis dizer que todas as classes que dependem umas das outras tem que ficar no mesmo pacote?

Que lambança hein? Vamos deixar tudo no java.lang entaum :lol:

E não vejo onde seria um problema criar um pacote FACADE, contendo os facades do componente na aplicação.

Pode me explicar melhor?

[]'s

Oi,

Pense no DAO e no Facade como camadas ou abstrações do seu sistema

• O DAO é uma forma de abstrair como o seu objeto deve ser salvo, este objeto pode ser salvo usando SQL em um banco de dados, ou então arquivo texto, qualquer coisa, mas você não precisa saber isso porque o DAO esconde estes detalhes de você ( o cliente que vai usar o DAO )

• O Facade é uma forma de abstrair outras camadas do seu sistema ou subsistemas, ele serve para encapsular uma chamada, por exemplo, o seu cliente precisa fazer uma validação do login do usuário, mas nestes caso ele precisa acessar o banco de dados ou ldap e validar com os dados da sessão do usuário, o Facade ou Fachada vai esconder estes detalhes de você e neste caso você irá basicamente chamar um método que internamente realiza toda essa implementação…

O primeiro é um design pattern da SUN - Core JEE Patterns - o segundo é um design pattern do livro do GOF (Gang Of For)

O DAO formar um pacote até que vai, mas o Façade ? convenhamos que não faz muito sentido uma classe ser um pacote ainda mais quando ela depende de outras.

Ambos são design patterns , mas pacotes não devem ser formados em torno de design patterns e sim em torno de funcionalidades.

Vc quis dizer que todas as classes que dependem umas das outras tem que ficar no mesmo pacote?

Não. Eu disse que Façade pertence no mesmo pacote das classes que ela invoca. O objetivo do padrão façade é excatamente simplificar o uso de uma camada, uma camada é um conjunto de classes ,logo faz mais sentido se o Façade estiver junto dassas classes. Até porque pode ser necessário usar acesso de pacote que serve exactamente para facilitar esse tipo de construção.

O DAO formar um pacote até que vai, mas o Façade ? convenhamos que não faz muito sentido uma classe ser um pacote ainda mais quando ela depende de outras.

Ambos são design patterns , mas pacotes não devem ser formados em torno de design patterns e sim em torno de funcionalidades.

Vc quis dizer que todas as classes que dependem umas das outras tem que ficar no mesmo pacote?

Não. Eu disse que Façade pertence no mesmo pacote das classes que ela invoca. O objetivo do padrão façade é excatamente simplificar o uso de uma camada, uma camada é um conjunto de classes ,logo faz mais sentido se o Façade estiver junto dassas classes. Até porque pode ser necessário usar acesso de pacote que serve exactamente para facilitar esse tipo de construção.

Entendi.

Mas para mim o Façade também pode ser entendido como uma fina camada entre as camadas (encapsulando subsistemas), daí um outro pacote para deixar mais clara a separação. A não ser que se faça necessário utilizar o mesmo pacote como vc disse.

Mas creio que é questão de estilo.

[]'s

O DAO formar um pacote até que vai, mas o Façade ? convenhamos que não faz muito sentido uma classe ser um pacote ainda mais quando ela depende de outras.

Ambos são design patterns , mas pacotes não devem ser formados em torno de design patterns e sim em torno de funcionalidades.

Vc quis dizer que todas as classes que dependem umas das outras tem que ficar no mesmo pacote?

Não. Eu disse que Façade pertence no mesmo pacote das classes que ela invoca. O objetivo do padrão façade é excatamente simplificar o uso de uma camada, uma camada é um conjunto de classes ,logo faz mais sentido se o Façade estiver junto dassas classes. Até porque pode ser necessário usar acesso de pacote que serve exactamente para facilitar esse tipo de construção.

Entendi.

Mas para mim o Façade também pode ser entendido como uma fina camada entre as camadas (encapsulando subsistemas), daí um outro pacote para deixar mais clara a separação. A não ser que se faça necessário utilizar o mesmo pacote como vc disse.

Mas creio que é questão de estilo.

[]'s

não. Não é questão de estilo. Façade designa o padrão de projeto para uma classe. Não ha como usar isso para referenciar uma “fina camada entre camadas”. Camada é camada, classe é classe.

Façade não é uma camada.

Uma camada que fica entre outras camadas com objetivo de ajustar as coisas é chamada Camada de Integração. Não tem nada a ver com Façade.

Muito obrigado aos dois ^^"

deu pra mim ter uma noção do que é… agora eh soh estudar ^^’

O DAO formar um pacote até que vai, mas o Façade ? convenhamos que não faz muito sentido uma classe ser um pacote ainda mais quando ela depende de outras.

Ambos são design patterns , mas pacotes não devem ser formados em torno de design patterns e sim em torno de funcionalidades.

Vc quis dizer que todas as classes que dependem umas das outras tem que ficar no mesmo pacote?

Não. Eu disse que Façade pertence no mesmo pacote das classes que ela invoca. O objetivo do padrão façade é excatamente simplificar o uso de uma camada, uma camada é um conjunto de classes ,logo faz mais sentido se o Façade estiver junto dassas classes. Até porque pode ser necessário usar acesso de pacote que serve exactamente para facilitar esse tipo de construção.

Entendi.

Mas para mim o Façade também pode ser entendido como uma fina camada entre as camadas (encapsulando subsistemas), daí um outro pacote para deixar mais clara a separação. A não ser que se faça necessário utilizar o mesmo pacote como vc disse.

Mas creio que é questão de estilo.

[]'s

não. Não é questão de estilo. Façade designa o padrão de projeto para uma classe. Não ha como usar isso para referenciar uma “fina camada entre camadas”. Camada é camada, classe é classe.

Façade não é uma camada.

Uma camada que fica entre outras camadas com objetivo de ajustar as coisas é chamada Camada de Integração. Não tem nada a ver com Façade.

A definição do padrão Façade diz:

This design pattern provides a unified interface to a set of interfaces in a
subsystem. It defines a higher-level interface that makes the subsystem
easier to use. A facade is an object that provides a simplified interface to a
larger body of code, such as a class library.

Não diz que o padrão se aplica a UMA classe (embora possa ser), mas sim a um subsistema.

Diz que é uma INTERFACE UNIFICADA de alto nível.

Isso não pode ser entendido como uma camada?

Flw.

O DAO formar um pacote até que vai, mas o Façade ? convenhamos que não faz muito sentido uma classe ser um pacote ainda mais quando ela depende de outras.

Ambos são design patterns , mas pacotes não devem ser formados em torno de design patterns e sim em torno de funcionalidades.

Vc quis dizer que todas as classes que dependem umas das outras tem que ficar no mesmo pacote?

Não. Eu disse que Façade pertence no mesmo pacote das classes que ela invoca. O objetivo do padrão façade é excatamente simplificar o uso de uma camada, uma camada é um conjunto de classes ,logo faz mais sentido se o Façade estiver junto dassas classes. Até porque pode ser necessário usar acesso de pacote que serve exactamente para facilitar esse tipo de construção.

Entendi.

Mas para mim o Façade também pode ser entendido como uma fina camada entre as camadas (encapsulando subsistemas), daí um outro pacote para deixar mais clara a separação. A não ser que se faça necessário utilizar o mesmo pacote como vc disse.

Mas creio que é questão de estilo.

[]'s

não. Não é questão de estilo. Façade designa o padrão de projeto para uma classe. Não ha como usar isso para referenciar uma “fina camada entre camadas”. Camada é camada, classe é classe.

Façade não é uma camada.

Uma camada que fica entre outras camadas com objetivo de ajustar as coisas é chamada Camada de Integração. Não tem nada a ver com Façade.

A definição do padrão Façade diz:

This design pattern provides a unified interface to a set of interfaces in a
subsystem. It defines a higher-level interface that makes the subsystem
easier to use. A facade is an object that provides a simplified interface to a
larger body of code, such as a class library.

Não diz que o padrão se aplica a UMA classe (embora possa ser), mas sim a um subsistema.

Diz que é uma INTERFACE UNIFICADA de alto nível.

Isso não pode ser entendido como uma camada?

não.
“higher-level interface” significa “interface de nivel mais alto”. A palavra chave aqui é “mais alto”.
Vc tem interfaces normais com as quais criou o sistema. Agora vc cria uma de nivel mais alto.
A forma de criar uma interface (um contrato) é implementando classes.
O padrão não se aplica ao subsistema, ele se aplica à interface de acesso ao subsistema. É totalmente diferente.

A ideia do façade é convergencia: em vez de utilizar N classes , vc utiliza apenas uma que faz o trabalho mais comum.
Um bom exemplo disto são os managers do JasperReports. As classes Jasper****Manager são façades para o resto do Jasper e implementam formas simples de utilizar a biblioteca. (repare que todos os métodos são estáticos - já que o façade é um padrão de responsabilidade e não tem implementação especifica) Todos eles estão no pacote engine.

Eles formam uma camada ? Não.

O DAO formar um pacote até que vai, mas o Façade ? convenhamos que não faz muito sentido uma classe ser um pacote ainda mais quando ela depende de outras.

Ambos são design patterns , mas pacotes não devem ser formados em torno de design patterns e sim em torno de funcionalidades.

Vc quis dizer que todas as classes que dependem umas das outras tem que ficar no mesmo pacote?

Não. Eu disse que Façade pertence no mesmo pacote das classes que ela invoca. O objetivo do padrão façade é excatamente simplificar o uso de uma camada, uma camada é um conjunto de classes ,logo faz mais sentido se o Façade estiver junto dassas classes. Até porque pode ser necessário usar acesso de pacote que serve exactamente para facilitar esse tipo de construção.

Entendi.

Mas para mim o Façade também pode ser entendido como uma fina camada entre as camadas (encapsulando subsistemas), daí um outro pacote para deixar mais clara a separação. A não ser que se faça necessário utilizar o mesmo pacote como vc disse.

Mas creio que é questão de estilo.

[]'s

não. Não é questão de estilo. Façade designa o padrão de projeto para uma classe. Não ha como usar isso para referenciar uma “fina camada entre camadas”. Camada é camada, classe é classe.

Façade não é uma camada.

Uma camada que fica entre outras camadas com objetivo de ajustar as coisas é chamada Camada de Integração. Não tem nada a ver com Façade.

A definição do padrão Façade diz:

This design pattern provides a unified interface to a set of interfaces in a
subsystem. It defines a higher-level interface that makes the subsystem
easier to use. A facade is an object that provides a simplified interface to a
larger body of code, such as a class library.

Não diz que o padrão se aplica a UMA classe (embora possa ser), mas sim a um subsistema.

Diz que é uma INTERFACE UNIFICADA de alto nível.

Isso não pode ser entendido como uma camada?

não.
“higher-level interface” significa “interface de nivel mais alto”. A palavra chave aqui é “mais alto”.
Vc tem interfaces normais com as quais criou o sistema. Agora vc cria uma de nivel mais alto.
A forma de criar uma interface (um contrato) é implementando classes.
O padrão não se aplica ao subsistema, ele se aplica à interface de acesso ao subsistema. É totalmente diferente.

A ideia do façade é convergencia: em vez de utilizar N classes , vc utiliza apenas uma que faz o trabalho mais comum.
Um bom exemplo disto são os managers do JasperReports. As classes Jasper****Manager são façades para o resto do Jasper e implementam formas simples de utilizar a biblioteca. (repare que todos os métodos são estáticos - já que o façade é um padrão de responsabilidade e não tem implementação especifica) Todos eles estão no pacote engine.

Eles formam uma camada ? Não.

O Façade eh uma camada de convergência então.

Ele que define a comunicação dos meus subsistemas através do contrato da interface de alto nível.

Uma camada para mim é uma divisão. Se vc tiver uma visão panorâmica de uma aplicação que utiliza Façades e ir tirados as camadas, vc vai enxergar a camada abaixo do Façade? Não.

Assim como vc citou o Jasper, eu utilizo os managers e nem sei o que ele faz com isso.

Por isso eu disse que eh uma questão de estilo, se vc quiser super granularizar a sua aplicação vc pode, o que aliás é uma tendência OO com seus prós e contras.

Foxlol:

O Façade eh uma camada de convergência então.

Ele que define a comunicação dos meus subsistemas através do contrato da interface de alto nível.

Uma camada para mim é uma divisão. Se vc tiver uma visão panorâmica de uma aplicação que utiliza Façades e ir tirados as camadas, vc vai enxergar a camada abaixo do Façade? Não.

Assim como vc citou o Jasper, eu utilizo os managers e nem sei o que ele faz com isso.

Por isso eu disse que eh uma questão de estilo, se vc quiser super granularizar a sua aplicação vc pode, o que aliás é uma tendência OO com seus prós e contras.

Façade não é uma camada.
Se fosse uma camada eu não poderia conseguir acessar os objetos da camada abaixo. E isso não se verifica. Eu posso usar os objetos normais eu apenas não quero usar.

Se Façade fosse uma camada que protege outra camada assim

A -> Façade ->B

A camada A só poderia acessar B através do façade. Mas isto é falso. ‘A’ pode escolher entre acessar dessa forma ou assim

A -> B

Mas se A acessaa B sem passar pela Façade isso viola as regras de camadas, pois uma camada superior está acessando directamente camadas inferiores sem passar pelas intermédias. Isto é errado e portanto nunca poderia ser um padrão.

O Façade representa um utilitário que simplifica o uso da camada, mas ele mesmo pertence a essa camada.
‘A’ pode acessar B ou F, o que ela preferir. Façade não é um isolador. Isso é uma mal-compreensão comum do padrão.
Façade é um simplificador.

sergiotaborda:

Foxlol:

O Façade eh uma camada de convergência então.

Ele que define a comunicação dos meus subsistemas através do contrato da interface de alto nível.

Uma camada para mim é uma divisão. Se vc tiver uma visão panorâmica de uma aplicação que utiliza Façades e ir tirados as camadas, vc vai enxergar a camada abaixo do Façade? Não.

Assim como vc citou o Jasper, eu utilizo os managers e nem sei o que ele faz com isso.

Por isso eu disse que eh uma questão de estilo, se vc quiser super granularizar a sua aplicação vc pode, o que aliás é uma tendência OO com seus prós e contras.

Façade não é uma camada.
Se fosse uma camada eu não poderia conseguir acessar os objetos da camada abaixo. E isso não se verifica. Eu posso usar os objetos normais eu apenas não quero usar.

Se Façade fosse uma camada que protege outra camada assim

A -> Façade ->B

A camada A só poderia acessar B através do façade. Mas isto é falso. ‘A’ pode escolher entre acessar dessa forma ou assim

A -> B

Mas se A acessaa B sem passar pela Façade isso viola as regras de camadas, pois uma camada superior está acessando directamente camadas inferiores sem passar pelas intermédias. Isto é errado e portanto nunca poderia ser um padrão.

O Façade representa um utilitário que simplifica o uso da camada, mas ele mesmo pertence a essa camada.
‘A’ pode acessar B ou F, o que ela preferir. Façade não é um isolador. Isso é uma mal-compreensão comum do padrão.
Façade é um simplificador.

Entendo, mas são camadas lógicas.

Vc concordou que DAO é uma camada certo?

Mas eu posso acessar o banco de dados da View muito bem sem utilizar a camada DAO:

V -> BD

Ao invés de:

V -> N CAMADAS -> ->DAO -> BD

Para mim são apenas diviões lógicas para solucionar (evitar) problemas. Por isso em vez de acessar o banco direto da minha view eu passo pelas camadas da aplicação.

Não. DAO não é uma camada. DAO pertence numa camada.
O que eu disse foi : “O DAO formar um pacote até que vai”. Pacote não é camada.

Mas eu posso acessar o banco de dados da View muito bem sem utilizar a camada DAO:
(…)
Para mim são apenas diviões lógicas para solucionar (evitar) problemas. Por isso em vez de acessar o banco direto da minha view eu passo pelas camadas da aplicação.

se vc tem um sistema com camadas vc não deve pular as do meio (bypass). Isso é errado.
Vc pode, mas não é correto.

Eu estou-me baseado no que é correto. Se formos para o “eu faço o que eu quiser” então este topico nem tem sentido…

sergiotaborda:

Foxlol:

Entendo, mas são camadas lógicas.

Vc concordou que DAO é uma camada certo?

Não. DAO não é uma camada. DAO pertence numa camada.
O que eu disse foi : “O DAO formar um pacote até que vai”. Pacote não é camada.

Mas eu posso acessar o banco de dados da View muito bem sem utilizar a camada DAO:
(…)
Para mim são apenas diviões lógicas para solucionar (evitar) problemas. Por isso em vez de acessar o banco direto da minha view eu passo pelas camadas da aplicação.

se vc tem um sistema com camadas vc não deve pular as do meio (bypass). Isso é errado.
Vc pode, mas não é correto.

Eu estou-me baseado no que é correto. Se formos para o “eu faço o que eu quiser” então este topico nem tem sentido…

Então se pacote não é camada eu posso criar meu pacote Façade e vai fazer sentido já que não é uma camada. Apenas estou agrupando meus façades.

Se DAO não é camada então pq vc acha sentido em colocá-los em um pacote? E o Façade que tbm não é camada não?

Seguindo a sua idéia o seu DAO teria que ficar no mesmo pacote que os componentes os quais ele provê o acesso.

[]'s

Não existe nada que diga que pacotes só devem separar camadas.

A questão pra mim é simples. Façade é algo mais genérico. Você pode ter diversos Façades num sistema, todos provem interfaces mais simples pra subsistemas, mas os subsistemas podem não ter nada a ver um com o outro. Que sentido tem em agrupar os Façades desse jeito?

DAOs, por outro lado, são sempre objetos que acessam dados. A definição não é tão genérica. Você os agrupa porque a funcionalidade deles é semelhante.

Abraço.

Cada um empacota como quer…

Porque eu crio pacote por funcionalidade a do DAO é muito particular e necessita de mais classes que apenas a classe do dao.
Precisa de exceções, conversores, etc…

Quer por todos os seus façades num pacote ? blz. Desde que não diga que eles formam uma camada está tranquilo.
Veja o exemplo do JasperReporsts, eles colocam no mesmo pacote que o façade está simplificando.

Sim, mas os componentes a que o DAO fornece acesso não estão no seu sistema. muito menos num pacote do seu projeto.
eles estão no banco, em arquivo, na rede, etc…

wagnerfrancisco:

Não existe nada que diga que pacotes só devem separar camadas.

A questão pra mim é simples. Façade é algo mais genérico. Você pode ter diversos Façades num sistema, todos provem interfaces mais simples pra subsistemas, mas os subsistemas podem não ter nada a ver um com o outro. Que sentido tem em agrupar os Façades desse jeito?

DAOs, por outro lado, são sempre objetos que acessam dados. A definição não é tão genérica. Você os agrupa porque a funcionalidade deles é semelhante.

Abraço.

Wagner, eu estou falando de UMA aplicação.

Se os seus Façades acessam subsistemas que não tem nada a ver um com o outro, não deveriam nem estar na mesma aplicação concorda?

Para mim o argumento que vc e o Sérgio tão usando para separar o DAO e não separar o Façade não tá fazendo sentido.

Meus Façades tem a funcionalidade de prover uma interface para meus substistemas (os quais tem a ver um com os outros) e meus DAO’s acessar dados da minha aplicação. Os dados não são os mesmos para cada DAO, embora participem de um mesmo contexto.

Daí o meu ponto, eu agrupo por contexto digamos, não por funcionalidade. Mesmo que o Façade seja ou não uma camada tanto faz pra mim, é só uma definição.

Então EU VOU SEPARARRRR OS PACOTEEEEEEEEEEESSSSSSSSSSSSSSSSSSS Ahhhhhhhhhh…hOAUIEhUIOAEHuiae zuera! :lol:

Mas então, postem alguns exemplos de estrutura que vcs usam nos projetos para eu ter uma idéia.

Vlw

org.xtpo.app.domain
org.xtpo.app.persistance <- os daos estao aqui
org.xtpo.app.services <- os façades estão aqui
org.xtpo.app.outros_pacotes_especificos

FACADE é ou não é uma camada, eis a questão ?!?
Eu estou tentando descobrir o que é esse tal desse FACADE.

Moro em Fortaleza. Estou trabalhando numa empresa que estou com um problemão, estou tentando descobrir,
como funciona esse tal desse MVC (model view e controlle), muito complicado mesmo,
NA WEB-INF/classes/br/com/empresa/usuario/ aí vem as pastas config, controle, criptografia, dao, FACADE, mail, model, relatorios, mail, web (actions e form)

Apaguei uma classe da DAO chamada de processoDAO.class onde tem os metodosde cancelar processo (nesses metodos tem as consultas sql de consultar processos não cancelados para poder cancelar), mais só quando apaguei o processoDAO.class a funçaõ de cancelar o sistema continuo funcionando. Que estranho eu pensei que apagando essa classe ia ocorre algum erro. EStou tentando descobrir…

Caro Inforjor,

Para saber mais sobre Facade dê uma olhada nesse tópico aqui , nesse site aqui e aqui . Acho que com isso vc vai tirar boa parte das dúvidas.
Mas para resumir, ele não é uma camada a mais no seu sistema ele apenas faz parte de uma das camadas.
Como você lerá em um dos links acima: “It hides the complexities of the system and provides an interface to the client from where the client can access the system.”

Bem, sobre vc ter deletado uma DAO de um sistema e não ter causado falhas, pensando rápido, eu acho q ou vc não fez o build do sistema após apagar, ou ele realmente não está servindo para nada mesmo… :shock:

Boa sorte…

* com.app.doctor
* com.app.drug
* com.app.patient
* com.app.presription
* com.app.report
* com.app.security
* com.app.webmaster
* com.app.util
* and so on...

http://www.javapractices.com/topic/TopicAction.do?Id=205

Olha aí meu nome é JOEL tbm “joellobo” .

Já descobri o mistério da FACADE.

Na WEB-INF/classes/br/com/empresa/facade

é so criar uma classe: botão esq./ new /classe, aí criará uma arq .java no pacote (SRC source).

Aí é só mandar a ver (implementar), a facade.

passa por varias paginas primeiro na JSP -> Action -> facade -> controle -> DAO (que faz as consultas com o banco que no meu caso MYSQL)

talvés não entendam ou não to explicando de forma clara,
so to resumindo pq to meio apresado.

sergiotaborda:

Foxlol:

Mas então, postem alguns exemplos de estrutura que vcs usam nos projetos para eu ter uma idéia.

org.xtpo.app.domain
org.xtpo.app.persistance <- os daos estao aqui
org.xtpo.app.services <- os façades estão aqui
org.xtpo.app.outros_pacotes_especificos

Taborda,

Vocẽ coloca todos as classes de domínio na package domain, todos daos em persistence (ops… dao não era para sistemas orientado a Dados? :P), todos os faces em services?

Você não cria packages para cada “divisão” do seu domínio?