Olá a todos!
Se eu tenho as camadas:
E uma interface com métodos CRUD e uma classe que implementa essa interface, chamando os métodos de PessoaDAO, isso é uma outra camada? ou faz parte de uma já existente?
Se eu estiver errando em algum conceito, por favor me corrijam…
Obrigado
Ao meu ver esse cara faz parte da camada de persistência. Me corijam se eu estiver errado…
Abraços…
[quote=felipeaqueiroz]Olá a todos!
Se eu tenho as camadas:
E uma interface com métodos CRUD e uma classe que implementa essa interface, chamando os métodos de PessoaDAO, isso é uma outra camada? ou faz parte de uma já existente?
Se eu estiver errando em algum conceito, por favor me corrigam…
Obrigado[/quote]
A meu ver pertence a camada de persistencia!
Só que eu vejo um erro ai, as regras de negocio pertencem ao dominio e não a camada do aplicativo. Se não o dominio só vai ter um monte de classes burras!
Muito obrigado pela ajuda,
Então qual a diferença entre a camada de aplicativo e a de domínio?
eu teria um camada de serviço onde teria a interface uma serviceImpl para as implementações e uma core para os DAOS, resumindo:
service --> Interface
serviceImpl --> Impl
core --> DAOS
se bem que depois que comecei a utilizar injeção de dependência e a spec J2EE 6, em projetos pequenos tenho repensado o uso de DAOS, digo se realmente é necessario ?
Interessante o q vc falou aix.
Vc tem algum exemplo ou algum link de como ficaria sem DAO usando a DI?
[quote=felipeaqueiroz]Muito obrigado pela ajuda,
Então qual a diferença entre a camada de aplicativo e a de domínio?[/quote]
A camada de aplicativo faz “operações” no dominio. O dominio tem as regras, mas quem trabalha com essas regras é o aplicativo. Um exemplo, você só pode vender para clientes que tenham um saldo possitivo. Essa verificação é feita pela classe Venda, é uma invariante dela. Digamos ao fazer Venda.NovaVendaPara(Cliente), ela levantaria uma execção, pois não pode vender para esse cliente. Só que que quem realiza a operação de venda, ou seja pega os objetos Cliente e a Venda e faz Venda.NovaVendaPara(Cliente) é o aplicativo. Imagine o aplicativo como as operações que são feitas por uma pessoa no sistema, é um jeito simplista de pensar, mas para quem está começando é bom pois facilita. Imagine uma pessoa operando o “dominio” essa pessoa não conhece as regras, ela não sabe que não pode vender para um cliente X, ela vai tentar fazer a venda ao receber uma solicitação, mas ao fazer isso ela vai ver que não é possivel e com base nisso vai notificar para quem ela recebeu a solicitação que não foi possivel fazer a venda pelo motivo X, ou vai dizer que foi feito com sucesso.
A camada do aplicativo também fica responsável pelo controle de transação.
Então, nesse caso de ter uma camada de serviço com as classes service (interface) e serviceIml (classe de implementação), os DAOs iriam para uma camada core? Isso seria um outro nome para a camada de persistência ou os DAOs não fazem parte dessa camada?
É 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=luiz_renato]Interessante o q vc falou aix.
Vc tem algum exemplo ou algum link de como ficaria sem DAO usando a DI?[/quote]
ola Luiz, tenho repensado, mas utilizo rsrsrsrrs, mas em uns pequenos webservices que tenho, vejo que usando DI nem precisaria do DAO, pos ele ja esta fazendo quase nada, ou seja: eu injeto tudo que preciso, tudo esta ficando a cargo do container, então penso se eu usar NamedQueries, sacou ? e resolveria tudo numa classe só.
[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
O que poderia estar indo em recursos seria o caso se você utilizar entitybean.
No entanto fica muito uma conversa sobre nome de pacotes do que Arquitetura
No meu ver a arquitetura fica assim
JSP -> Controller -> EntityBean(Caso Exista) -> RegraDeNegocio -> Camada de Dados
Poderia ter um delegate (Entre controller e EntityBean), para quem não gosta assim como eu de desenvolver o service locator nas classes de controller
[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.
Muito obrigado mesmo, gente!
Vocês são demais! Agora entendi 