DAO's nas classes de negócio

Thiago Senna wrote:Não querendo ser folgado... Mas você possui alguma referência para nos indicar para estudar sobre os padrões Specification e QueryObject? Desde os fundamentos e um exemplo mostrando o caminho das pedras para implementá-los?
Obs: Ainda não pesquisei muito no google mas vou pesquisar com certeza.

Tem uma referncia ótima aqui.

mutano wrote:
Segundo o trecho acima, o padrão Repository pode ocasionar em uma camada a mais no design do sistema, dependendo do caso, tudo bem. Mas o que me deixou em dúvida foi a dependência de RepositoryImpl com DatabaseDao... me parece que os 2 ficam com uma dependência forte, ficando o RepositoryImpl sabendo como os dados são armazenados. Neste caso ele ficaria fora da camada de negócio? De repente este exemplo ficou bem abstraído e eu não entendi direito.

O Repositório sabe como os objetos são persistidos, em quais lugares, etc. Ele é um objeto na frotneira entre Negócios e Persistência.

mutano wrote:
Também sempre considerei MVC como apresentação, conforme a segunda afirmação, mas a primeira parece dizer o contrário... talvez não tenha ficado claro o que o Philip quiz dizer com a primeira afirmação e se puder esclarecer um pouco...

Neste diagrama:

O Model é composto por tudo menos o cercado em vermelho.

Fonte: http://fragmental.com.br/wiki/index.php?title=MVC_e_Camadas

Cara, eu preciso estudar muuuuuito

Tudo entendido sobre Repositorios e DAOs...
Mas eu ainda estou com uma duvida em um sistema que estamos iniciando agora (e que essa thread me ajudou bastante) que é o seguinte:
Nesse sistema, tem horas que eu "vou" num Oracle via JPA, outras em WebServices, outras na plataforma alta via MQSeries e outras em um XMLDB. Pois bem, o Repositorio e o DAO funcional perfeitamente nesses casos. Mas que objeto (nome e tipo) eu devo retornar nesses vários caminhos...
Hoje eu tenho um monte de DTOs... nesse caso, qual o conselho de vcs? E no caso do Entity do JPA? Eu não acho legal retornar um objeto todo anotado... o que fazer?!?

rodrigoallemand wrote:Mas que objeto (nome e tipo) eu devo retornar nesses vários caminhos...
Hoje eu tenho um monte de DTOs... nesse caso, qual o conselho de vcs? E no caso do Entity do JPA? Eu não acho legal retornar um objeto todo anotado... o que fazer?!?

Seu problema não tem tanto a ver com Repositórios ou DAOs e sim com objetos de negócio. Você deve retornar Entities e seus Aggregates segundo Domain Driven Design, que não necessariamente são Entities JPA mas que pdoem ser sem problemas. Anotações foram criadas exatamente para abstrair dos objetos infra-estrutura como persistência ou transações.

pcalcado wrote:Seu problema não tem tanto a ver com Repositórios ou DAOs e sim com objetos de negócio. Você deve retornar Entities e seus Aggregates segundo Domain Driven Design, que não necessariamente são Entities JPA mas que pdoem ser sem problemas.

Não conheço DDD a fundo... mas como essa camada de negocio ficará exposta para outros serviços (via JAR ou via transação remota) como seriam os objetos?!? Digo como seriam, assim, POJOs, destacados dos objetos utilizados no caminho até o repositorio real, etc...

pcalcado wrote:
Anotações foram criadas exatamente para abstrair dos objetos infra-estrutura como persistência ou transações.

Idem acima. Em alguns casos, esses objetos de negocio devem ser expostos para outro sistema. Não ficaria "feio" mandarmos um objeto com configurações de mapeamento anotadas?!? Em contra partida, duplicar objetos somente para tirar as anotações seria um tiro no pé, já que atualizações deverão ser em dois lugares agora...

O problema é: eu preciso expor objetos (POJOs). Vcs acham que ficaria "feio" expor objetos anotados?

This message was edited 2 times. Last update was at 02/09/2007 20:26:55

rodrigoallemand wrote:
Idem acima. Em alguns casos, esses objetos de negocio devem ser expostos para outro sistema. Não ficaria "feio" mandarmos um objeto com configurações de mapeamento anotadas?!? Em contra partida, duplicar objetos somente para tirar as anotações seria um tiro no pé, já que atualizações deverão ser em dois lugares agora...

Sem entrar no mérito das anotações, quando o assunto é integração, ficaria "feio" expor os próprios Pojos. Se assim o fizer estará acoplando suas aplicações cliente ao seu modelo, e isso é ruim. Imagine, se elas forem forçadas a recompilar suas aplicações toda hora que vc adiciona/atualiza/exclui um atributo em qualquer Pojo do seu modelo, .

XSDs podem ser opções mais elegantes quando o problema é definir "padrões" de dados que devem trafegar entre aplicações.

JavaEvangelist Membro desde: 27/03/2006 11:11:34 Mensagens: 340 Offline

pcalcado wrote: Dificilmente existe um Entity (falando no jargão DDD) que seja criado manualmente, geralmente ele é criado por um Factory Method em um Service (outra vez DDD) que já cuida destas coisas.

Não sei se estou misturando as bolas mas,

Este factory method também faz e registro do objeto como limpo em uma unidade de trabalho?

JavaEvangelist Membro desde: 27/03/2006 11:11:34 Mensagens: 340 Offline

pcalcado wrote:

Thiago Senna wrote:Não querendo ser folgado... Mas você possui alguma referência para nos indicar para estudar sobre os padrões Specification e QueryObject? Desde os fundamentos e um exemplo mostrando o caminho das pedras para implementá-los?
Obs: Ainda não pesquisei muito no google mas vou pesquisar com certeza.

Tem uma referncia ótima aqui.

Será que resumo da infoq chega a falar sobre isso? Vou dar uma olhada...

http://www.infoq.com/minibooks/domain-driven-design-quickly

JavaEvangelist Membro desde: 27/03/2006 11:11:34 Mensagens: 340 Offline

Taz wrote:
Sem entrar no mérito das anotações, quando o assunto é integração, ficaria "feio" expor os próprios Pojos. Se assim o fizer estará acoplando suas aplicações cliente ao seu modelo, e isso é ruim. Imagine, se elas forem forçadas a recompilar suas aplicações toda hora que vc adiciona/atualiza/exclui um atributo em qualquer Pojo do seu modelo.

Desculpa se estou sendo muito burro!

Você só precisa recompilar uma classe quando a interface de uma classe que ela depende muda! (Ou to viajando?)

Eu penso que se as interfaces dos seus pojos são estaveis vc pode acoplar qualquer coisa a eles. A implementação pode mudar a qualquer hora sem que vc tenha que recompilar seu cliente!

Falo de interface como sendo os métodos que a classe fornece!

"Teve uma época que li programe somente para "interfaces"! Sai criando interface para tudo! sem nem ter necessidade! hauhahauhauha o mula!