Oi!
onde eu posso encontrar material que me auxilie a definir esses tipos de pacotes?
eu fiz um tutorial, mas foi só passo a passo… mas não explicou porque eu teria que fazer esse encapsulamento
obrigado =D
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:
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.[/quote]
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.[/quote]
Vc quis dizer que todas as classes que dependem umas das outras tem que ficar no mesmo pacote?
[/quote]
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.[/quote]
Vc quis dizer que todas as classes que dependem umas das outras tem que ficar no mesmo pacote?
[/quote]
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.[/quote]
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.[/quote]
Vc quis dizer que todas as classes que dependem umas das outras tem que ficar no mesmo pacote?
[/quote]
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.[/quote]
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[/quote]
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.[/quote]
Vc quis dizer que todas as classes que dependem umas das outras tem que ficar no mesmo pacote?
[/quote]
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.[/quote]
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[/quote]
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.
[/quote]
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.[/quote]
Vc quis dizer que todas as classes que dependem umas das outras tem que ficar no mesmo pacote?
[/quote]
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.[/quote]
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[/quote]
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.
[/quote]
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?
[/quote]
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.[/quote]
Vc quis dizer que todas as classes que dependem umas das outras tem que ficar no mesmo pacote?
[/quote]
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.[/quote]
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[/quote]
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.
[/quote]
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?
[/quote]
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.
[/quote]
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.
[quote=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.[/quote]
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.
[quote=sergiotaborda][quote=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.[/quote]
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.
[/quote]
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.
[quote]
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.[/quote]
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…
[quote=sergiotaborda][quote=Foxlol]
Entendo, mas são camadas lógicas.
Vc concordou que DAO é uma camada certo?
[/quote]
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.
[quote]
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.[/quote]
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…[/quote]
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…
[quote=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.[/quote]
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