[quote=felipeaqueiroz][quote=sergiotaborda]É claro que você pode definir os seus próprios nomes para as coisas, embora isso não seja muito apurado tecnicamente.
Existem vários modelos de arquitetura padrão. Eu pessoalmente gosto do padrão em 5 andares: Cliente, Apresentação, Dominio, Integração, Recursos
O padrão DAO e suas interfaces pertencem no andar de integração. Repare que Persistencia é um tipo de integração. Ler aquivos é outra. Ler webservice é outra e assim vai.
Camada de aplicativo não faz muito sentido o nome. Está mais para o front end do andar de dominio que recebe chamadas de fora. Se imaginarmos o andar de dominio como uma cebola essa camada que invoca o dominio pode ser considera a casca. Por outro lado podemos também considerá-la a camada de business delegates que pode existir no andar de apresentação. [/quote]
Eu também acho bem elegante esse padrão que usa Cliente, Apresentação, Dominio, Integração e Recursos.
Mas ai então, teríamos:
Cliente (Browser)
Apresentação (JSP’s)
Dominio (Classe Pessoa e regras de negócio)
Integração (PessoaDAO e outras formas de integração)
Recursos <== O que viria aqui?
Mais uma vez, muito obrigado pela ajuda[/quote]
Suponto um sistema web:
Cliente (Browser) - ok
Apresentação (JSP’s) - Não apenas o JSP. Todo o mecanismo de controle de fluxo. Strut, Spring MVC, JSF… o que for que usa no servlet container.
Dominio (Classe Pessoa e regras de negócio) - Aqui pertencem também classes Service (session beans, por exemplo) , Validators, Repositorios (não os DAO, mas os objetos que contém as queries de pesquisa), Specifications, etc…
Integração (PessoaDAO e outras formas de integração) - ok. Modernamente se usa o padrão DomainStore. O DAO é literalmente do seculo passado.
Hibernate e JPA são implementações do padrão DomainStore
Recursos <== O que viria aqui? : Aqui vêm as entidades e todos os objetos que representam estado no seu sistema e que de alguma forma são persistido , seja em BD ou seja em arquivo. Algumas pessoas dizem que os recursos são o banco e os arquivos, mas na verdade é que está dentro deles e como vc representa isso em objetos. Arquivos de i18n tb estão aqui.
Modernamente, devido aos frameworks o conceito é que um unico objeto sirva como entidade , objeto de visão e DTO de si mesmo. Este conceito é util 80% das vezes, mas existe um 20% onde vc precisa de objetos especializados para a view e os recursos. Deste ponto de vista os objetos de recurso e as entidades são coisas difentes. Mas é uma diferença conceptual. O link que eu passei tenta explicar que na realidade exitem 3 sabores de objetos de estado (estado de apresentação, estado de negocio, estado de sistema). Antigamente vc tinha os DTO fazendo o papel dos dois da ponta e os entity beans fazendo o papel do estado de negocio. Hoje isso morreu e um POJO serve para os três.
Em suma, vc não cria um pacote chamado recursos. É meio que implicito.