Design de Classes: Façade, DAO e Beans

Programação Arquitetura
#1

Pessoal, estou fazendo um diagrama de classes para um sistema web, usando tapestry. Pretendo usar o padrão DAO e Façade.

Há momentos em que preciso que um bean retorne algum objeto da base de dados, daí ele teria que acessar o DAO ou um Façade.
Exemplo:

class NotaFiscal
{
      public ItemNota getItemNota()
      {
                return DAONotaFisca.getItemNotaFiscal();
       }
}

Minha dúvida é se posso criar instâncias do DAO ou do Façade dentro do bean para isto, ou se isso deve ser delegado à outra classe p/ que o bean continue puro e simplista ??? Será q estou ofendendo algum pattern ???

[/code]

#2

O DAO deve prover a lista para o Bean.

PS: Facade não possui cecidilha por ser uma palavra francesa e a tradução é fachada.

#3

Momento cultura: Façade tem cedilha JUSTAMENTE por ser do francês, Louds. No ingles, virou uma daquelas palavras elefante-branco que tem acentuacao. Outro exemplo eh naïve, com treminha no i e tudo. :wink:

#4

Deixa eu ver se entendi, é melhor eu deixar o bean magrinho e bota este metódo getItemNota no DAO ref. a classe NotaFiscal, asim:

classe Nota Fiscal

class NotaFiscal 
{ 
     private int numero;
     . . . //outras propriedades
     public get int numero;
     . . . //outros métodos
}

classe DAONotaFiscal


class DAONotaFiscal 
{ 
       public ItemNota[] getItemNota() 
      { 
            //Faz conexão, criar um array de ItemNota
      } 
}

É isto mesmo??? :multi:

#5

Burro, burro, burro.

  • Se escondendo de vergonha * :oops: :oops: :oops: :oops:
#6

:? óóóia desvio do tópico aí minha gente!!

#7

Respondendo ao cezarsg e continuando com o topico :wink:

é assim mesmo…
Devemos tomar cuidado, pois ao implementar o DAO o objeto que representa um objeto de dados (NotaFiscal) deve somente fazer o que lhe foi determinado, ou seja, representar um objeto de dados para transportar essas dados (Value Object).
Todo e qualquer tipo de recuperação de dados ou ação de negócio deve ser atribuido a classe que implementa o DAO (DAONotaFiscal)

Eu sugiro que você dê uma olhada na definição de 10 arquiteturas desenvolvida pelo pessoal da Globalcode http://www.globalcode.com.br/content/jaref/index.jsp
Pode servir como um guia para ajudá-lo no desenvolvimento do seu projeto. :wink:

espero ter ajudado. :slight_smile:
e boa sorte!

#8

gleise, obrigado pela atenção. Pelo que entendi, naquele projeto, os DAOs tem responsabilidade apenas de persistência e consulta sobre a base de dados. Mas daí fica igual ao que botei no primeiro tópico. :shock:

Se eu delegar para o DAO, somente ele vai saber sobre sobre as associações da nota fiscal. Daí, a nota fiscal deve pedir os itemsNotaFiscal ao DAONotaFiscal, como está no último código.

Já me falaram q isto nem é orientação objeto.

#9

Como vcs decidem que métodos um bean deve ter (além dos métodos de acesso).

Estou envolvido num projeto que inicialmente, tinha colocado alguns métodos que dependiam de uma consulta a base de dados. Mas já estou usando um DAO. Estou precisando saber se coloco o DAO dentro do bean p/ ajudá-lo, ou crio o método no DAO ao invés do Bean.

#10

Pra mim o Bean só deve ter os metodos de acesso…

Eu por exemplo nos meus códigos pegaria a NF pelo NfDAO e no objeto nf acessaria o nf.getItens, não precisa ir até o DAOItens se tiver tudo mapeado…

[]´s

#11

[quote=louds]
PS: Facade não possui cecidilha por ser uma palavra francesa .[/quote]

É exatamente ao contrário: em francês ha cedilha. Façade (com cedilha) é também uma palavra inglesa, mas os teclados ingleses não têm ç o que os obriga (os preguiçosos claro) a escrever apenas o c em textos. (ver por exemplo este texto em frances)

#12