Definição pacote DAO e pacote Facade

sergiotaborda wrote:

Foxlol wrote:
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.

This message was edited 2 times. Last update was at 02/12/2009 17:19:22

Foxlol wrote:
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.

Cada um empacota como quer...

Se DAO não é camada então pq vc acha sentido em colocá-los em um pacote?

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..

E o Façade que tbm não é camada não?

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.

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

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 wrote: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!

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

Vlw

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 3160 Offline

Foxlol wrote:
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

Thread.start() Membro desde: 30/11/2009 13:42:59 Mensagens: 25 Offline

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...

Boa sorte...

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

* 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

Thread.start() Membro desde: 30/11/2009 13:42:59 Mensagens: 25 Offline

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 wrote:

Foxlol wrote:
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?

), todos os faces em services?

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

Notícias, artigos e o maior fórum brasileiro sobre Java