DAO's nas classes de negócio

Debugger Membro desde: 05/04/2007 20:42:19 Mensagens: 67 Offline

Tipica discussao interessante que só tem fim quando alguem desiste de escrever...

Eu concordo com argumentos de vários que escreveram

1 - nomes são importantes pois criam um vocabulário em comum para que todos possam se comunicar mais facilmente. Mesmo que eu nao concorde com um nome, eu procuro saber o que ele significa para outros profissionais.. e tento explicar também como eu interpreto esse nome.

2 - Acho importante debater sobre o que Fowler, Evans (e outros) escreveram, assim podemos formar nossas própŕias opiniões.. Assim também podemos conhecer algo que é mais difundido do que nossas opiniões. Se alguem concorda com tudo que eles escreveram, pelo menos estão concordando com alguem que já refletiu bastante sobre os assuntos..

3 - Nossa "obrigação" é saber a teoria, mas na hora de por na prática saber decidir o que utilizar dela.. por exemplo: todos deveriam conhecer o conceito de Repositorio mesmo que nunca venham a implementar..

Acho que a discussao aqui acontece mais porque não existe uma verdade absoluta, porque cada um tem suas opiniões, interpretações e principalmente EXPERIÊNCIAS..

Talvez uns achem Repositorio algo extremamente importante e talvez outros não tenham sentido necessidade de usar. Não podemos esquecer que aqui temos pessoas de todos os tipos..

Fabio Kung wrote:Se eu percebo a necessidade de abstrair, refatoro e pronto. Acho que não vale a pena complicar muito o modelo com 1332423 abstrações e interfaces de tudo sem nem ter certeza da real necessidade.

Concordo plenamente!

(post sem utilidade nenhuma na discussão, mas fiquei muito feliz por alguém ter escrito isso)

Antes que eu me esqueça de novo:

Free book: Domain Driven Design Quickly

[]'s

Rodrigo Auler

Eu acho teoria importante, mas acho tb que um código/exemplo prático fala melhor do que 10 teorias:

Abaixo tenho o modelo:

Action -> Model/Manager/Repositório/??? -> DAO -> Impl DAO -> Banco

Será que assim ficaria melhor:

- Será que a action deveria acessar o DAO diretamente?

- Será que minha action virou o modelo?

- Será que a action deveria virar modelo?

- Será que o modelo deveria ser separado da action, mas poderia virar uma action não acoplada ao framework? (POJO ACTION)

- Estou começando a achar que a maneira mais bonita, de forma que sua aplicação ficaria o mais independente possível do framework em questão é:

framework mvc -> Modelo/Pojo Action -> DAO / Repository -> Implementação de DAO -> Banco de dados...

Assim vc teria uma action, que não seria na verdade uma action, mas sim uma espécie de model... O preço a pagar me parece claro tb: burocratização do processo... Seria como programar sem uma interface DAO e tentando deixar sua aplicação independente de banco de dados... (Model não é como DAO, não dá para fazer uma interface UserAction, ou seja, para abstrair o modelo de negócios...)

A dúvida que ainda tenho e se realmente vale a pena jogar o DAO pra dentro das entidades e deixá-las o mais esperto possível (segundo código postado) ou trabalhar com Entidades que apenas são envelopes de dados a a manipulação dessas entidades acontece por fora delas via DAO (primeiro código postado)...

pcalcado wrote:
Pense em Camadas. Repository faz com queobjetos de negócios só pensem em objetos de negócio. Leia Robert C. Martin sobre inversão de dependências.

Eu entendi. Só não enxergo nenhuma situação em que usar Repository num objeto de negócio em vez de DAO seja efetivamente vantajoso, na pratica. No fim, da na mesma.

Debugger Membro desde: 05/04/2007 20:42:19 Mensagens: 67 Offline

Vamos considerar a busca do melhor "design possivel"(se é que isso é possivel)

saoj wrote:
- Será que a action deveria acessar o DAO diretamente?

Não

saoj wrote:
- Será que minha action virou o modelo?

Não

saoj wrote:
- Será que a action deveria virar modelo?

Não

saoj wrote:
- Será que o modelo deveria ser separado da action, mas poderia virar uma action não acoplada ao framework? (POJO ACTION)

Não

Minha visão...
O Action, deve pegar os dados da fonte(web, swing) e repassar pra alguem.. Se usarmos DDD, o action poderia conversar com uma fachada que manipularia os objetos de negocio (é claro que com as regras desses objetos dentro deles mesmos)

Actions deveriam ser "burros" e apenas fazer validações de dados(não de negócios) conversões e formatações

Existe um livro muito legal que da uma passada em algumas "opções" de design chamado POJOs in Action

É um livro teorico/pratico e tem vários exemplos de código.. recomendo (Mas ele é um pouco superficial)

É claro que dependendo da situação, fazer um action acessar um DAO não é nenhuma heresia.. não vou dizer que nunca fiz isso..

O Action, deve pegar os dados da fonte(web, swing) e repassar pra alguem.. Se usarmos DDD, o action poderia conversar com uma fachada que manipularia os objetos de negocio (é claro que com as regras desses objetos dentro deles mesmos)

Eu tb tenho feito a coisa assim... Meu erro foi ter chamado essa classe que recebe os dados da action de JobManager, o que passa a idéia errada da coisa. Melhor seria JobLogic, JobSession, JobWork, etc. (alguém teria um nome melhor?)

Me restou a seguinte dúvida:

A action deve passar os dados para um JobWork desses da vida ou deve passar direto para um objeto Job de forma que o job saiba se virar para carregar tudo que ele precisa e fazer as operações no banco.

se virar = possuir dentro dele uma instância de JobRepository ou JobDAO de forma que ele possa se auto-carregar, e carregar outras dependencias que ele venha a ter.

O impasse aqui é que usando um JobWork, meu objetos podem ter uma tendencia de ser apenas envelope de dados... mas acho que uma coisa não tem nada haver com a outra, ou seja, usar um JobWork da vida não significa que meus objetos serão anêmicos...

Debugger Membro desde: 05/04/2007 20:42:19 Mensagens: 67 Offline

saoj wrote:

O Action, deve pegar os dados da fonte(web, swing) e repassar pra alguem.. Se usarmos DDD, o action poderia conversar com uma fachada que manipularia os objetos de negocio (é claro que com as regras desses objetos dentro deles mesmos)

Eu tb tenho feito a coisa assim... Meu erro foi ter chamado essa classe de JobManager, o que passa a idéia errada da coisa. Melhor seria JobLogic, JobSession, JobWork, etc. (alguém teria um nome melhor?)

*Service talvez

saoj wrote:
Me restou a seguinte dúvida:

A action deve passar os dados para um JobWork desses da vida ou deve passar direto para um objeto Job de forma que o job saiba se virar para carregar tudo que ele precisa e fazer as operações no banco.

se virar = possuir dentro dele uma instância de JobRepository ou JobDAO de forma que ele possa se auto-carregar, e carregar outras dependencias que ele venha a ter.

Ai que ta..
Fachadas ou não?
Eu usaria as fachadas.. não acho legal os actions conhecerem os objetos de negocio. Pra mim actions devem fazer somente o que eu falei anteriormente..

Eu faria como no uml que estou postando em anexo

Problema com seu exemplo: Action não tem nada a ver com Repository. Action é MVC e MVC é Camada de Apresentação, estamos falando da integração entre negócios e Persistência.

saoj wrote:Eu acho teoria importante, mas acho tb que um código/exemplo prático fala melhor do que 10 teorias:

Ponto interessante.

1) Já foram citados neste artigo diversas documentações que possuem vários exemplos, alguém se deu ao trabalho de ler pelo menos alguma?

2) Um exemplo, vinte exemplos,t rinta exemplos não conseguem explicar todos os casos, então não, ele não vale mais que 10 descrições de uma teoria (ou exemplo e teoria são antagônicos?)

Na boa, Sérgio, leia a documentação, depois poste aqui. Fica muito repetitivo ter a mesma pergunta feita de 30 maneiras diferentes e por mais que tentemos provavelmente não seremos tão claros quanto as pessoas que criaram ou catalogaram estas práticas. Fica difícil debater as idéias do Domain-Driven Design sem saber o que é Domain-Driven Design.

microfilo wrote:Eu entendi. Só não enxergo nenhuma situação em que usar Repository num objeto de negócio em vez de DAO seja efetivamente vantajoso, na pratica. No fim, da na mesma.

Segundo este pensamento dá na mesma fazer Action chamar DAO, ou nem ter DAO, afinal dá tudo na mesma. Ou melhoir: pra que interfaces? Use logo as implementações, dá na mesma.

Não, não dá. Se vale a pena usar no caso X ou não é outro assunto, mas pela enésima vez: DAO pode ser a implementação de repositório, repositório não precisa ser implementado por um DAO.

Na boa, Sérgio, leia a documentação, depois poste aqui. Fica muito repetitivo ter a mesma pergunta feita de 30 maneiras diferentes e por mais que tentemos provavelmente não seremos tão claros quanto as pessoas que criaram ou catalogaram estas práticas.

Sinceramente não entendo esse tipo de colocação, Phillip. Todos aqui estão trocando idéias e debatendo com educação, e acredito que eu e todo mundo aprendemos bastante com o tópico. Vc tb estava contribuindo bastante e de repente vêm com essa de "Na boa, Sérgio, leia a documentação para o tópico não ficar repetitivo", como se o foco negativo desse post estivesse em mim. É lamentável esse tipo de postura... É um comportamento no mínimo indelicado, para economizar nos adjetivos...

Pode dar a entender que vc está mais preocupado comigo do que com o tópico em si.

Bom, agradeço a todos que contribuiram e debateram, principalmente ao Fábio Kung e ao FelipeC... Aprendi bastante e agora mesmo estou refatorando meu sistema para melhor aplicar esses conceitos.

Fica difícil debater as idéias do Domain-Driven Design sem saber o que é Domain-Driven Design.

Ok, vou estudar mais. Me desculpe por vc ter perdido o seu precioso tempo discutindo com pessoas que não sabem o que é DDD.

felipec wrote:Fachadas ou não?
Eu usaria as fachadas.. não acho legal os actions conhecerem os objetos de negocio. Pra mim actions devem fazer somente o que eu falei anteriormente..

Eu não vejo problema que as actions conheça os objetos de negócio. As minhas actions conhecem minhas classes de repositório e minhas classes de serviço.

Uma dúvida, no seu diagrama o que você chama de fachada? O TransferService?

[]'s

Rodrigo Auler

pcalcado wrote:Problema com seu exemplo: Action não tem nada a ver com Repository. Action é MVC e MVC é Camada de Apresentação, estamos falando da integração entre negócios e Persistência.

saoj wrote:Eu acho teoria importante, mas acho tb que um código/exemplo prático fala melhor do que 10 teorias:

Ponto interessante.

1) Já foram citados neste artigo diversas documentações que possuem vários exemplos, alguém se deu ao trabalho de ler pelo menos alguma?

2) Um exemplo, vinte exemplos,t rinta exemplos não conseguem explicar todos os casos, então não, ele não vale mais que 10 descrições de uma teoria (ou exemplo e teoria são antagônicos?)

Na boa, Sérgio, leia a documentação, depois poste aqui. Fica muito repetitivo ter a mesma pergunta feita de 30 maneiras diferentes e por mais que tentemos provavelmente não seremos tão claros quanto as pessoas que criaram ou catalogaram estas práticas. Fica difícil debater as idéias do Domain-Driven Design sem saber o que é Domain-Driven Design.

microfilo wrote:Eu entendi. Só não enxergo nenhuma situação em que usar Repository num objeto de negócio em vez de DAO seja efetivamente vantajoso, na pratica. No fim, da na mesma.

Segundo este pensamento dá na mesma fazer Action chamar DAO, ou nem ter DAO, afinal dá tudo na mesma. Ou melhoir: pra que interfaces? Use logo as implementações, dá na mesma.

Não, não dá. Se vale a pena usar no caso X ou não é outro assunto, mas pela enésima vez: DAO pode ser a implementação de repositório, repositório não precisa ser implementado por um DAO.

Philip, às vezes para abstrair alguns conceitos, precisamos no mínimo de alguns exemplos tangíveis, para ver sua aplicação.

Acho válida a argumentação do Sérgio.

Fica complicado apenas citar Patterns e dar link para os mesmos , pois alguns conseguem abstrair outros não e tais exemplos, ajudariam reforçar o entendimento e até mesmo corrígi-los, pois alguns podem entender algo que na prática é diferente.

Já vi vários tópicos seus, com grande auxílio, mas falta o tal do exemplo tangível e acredito que para muitos, a referência acaba ficando confusa e seu empenho foi em vão.

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

Parece que ficou no ar alguma duvida sobre DAO X Repository e que Repository pode ser / implementar um DAO (Data Access Object)
Repository (Repository) é onde as entidades estão. Não onde os "dados brutos" estão , mas os objectos de negocio. A entidade Cliente tem quantas instâncias ? Onde elas estão ? no repository. Como uma entidade encontra as entidades que lhe cabem ? Por exemplo , como um pedido encontra seus itens ? Pelo repositório. Claro que os itens são injetados no pedido, mas como ?

O Repositório internamente identifica que Pedido tem um associação com PedidoItem e automaticamente faz (internamente)

Ou poderia injetar uma implementação de Collection, que fizesse lazy loading

Que depois faria o codigo de cima quando alguém consultasse a lista.

Por outro lado, o repositório está associado ao dominio. Um DAO está associado aos dados brutos e à tecnologia paras os acessar (Data Access Object)
Mas como o repositório preenche os dados das instâncias ?
Ele tem que usar um DAO. Porque? Porque os dados não estão em objetos na memória. Mesmo que estejam, provavelmente não estão na mesma forma em que o domínio os quer. O comum é estarem no banco de dados, mas poderiam estar no mecanismo prevalente, ou numa simples List ( por exemplo em ambiente de teste)
O repository isola a instancia do dominio do local onde as outras instancias estão , o DAO isola o repositorio de saber onde os dados estão.
Veêm a diferença ? Um trabalha com instancias do dominio, o outro com dados brutos.

O DAO isola também o mecanismo de procura. Para bancos ele usa SQL, mas para list provávelmente usa um filtro. O repository apenas passa ao DAO "o quê ele quer" e não o "como encontrar". O mesmo para os objectos de negocio que pedem o que querem e não dizem ao repository como encontrar.

Mas isto é a camada de negocios. Como seria na camada de visualização.
Se eu quiser listar todos os pedidos num table num html tenho que passar pelo repository ? Não. Basta usar o DAO. Não ha logica de negocios aqui. Apenas transferência de dados brutos.

O repositório é a forma como as instancias das entidades de negocio se comunicam e se encontram (repositório : onde todo o mundo está)
O dao é a forma como um repositório especifico executa esse trabalho.
Poderíamos ter repositório sem dao. Um exemplo classico é que o repositório seja um grafo gigante em que a raiz é um objeto anônimo que contém todas as coleções de todas as entidades de negocio que cotêm todas as referencias aos objetos que necessitam. Isso seria OO puro, mas isso não é tecnologicamente viável. Somos obrigados a guardar os dados de forma mastigada , e para isso que serve o DAO.

A interface de um DAO e de um Repository são muito semelhantes, mas elas não significam a mesma coisa. Não se pode pedir a um repository que encontre um objeto com base numa frase SQL, a um DatabaseDao, pode.
Mas a um InMemoryListDao não pode. Ou seja, a comunicação da intensão tb tem que ser abstraida de forma que o programador/objecto de negocio diga "o que quer" e "não como quer"
Claro que isto pode ser muito complicado, e, no caso geral serei obrigado a escrever o SQL na mão. Isto viola o encapsulamento que estou construindo com os DAO e os Repository. Isso nunca é bom. Claro, podem dizer que 99,99% dos casos usam banco de dados e que portanto usar SQL é tranquilo (quem diz SQL , diz EQL, HQL ,etc...) Mas , na verdade , é uma violação sim.
Quando no futuro , a tecnologia de persistência for outra, e o SQL não for mais a forma de procurar pela informação danou. Vai ter que haver outro software. Não se fizermos as coisas como deve ser. A lógica de negocio não depende do banco. Ela sempre será a mesma. Então se a tecnologia muda para outra coisa - digamos XQuery como exemplo - so teria que escrever um XQueryDAO. Mas e para as SQL que tive que escrever na mao ?

Para essas é criado um DAO especial que contém as SQL sofisticadas e retorna os dados. Ou seja, eu não passo o SQL , ele já está lá dentro. O repositório traduz isso para a camada de negocio. A camada de negocio não sabe que existem dois DAO no repositório. Mas ele sabe que DAO chamar dependendo da pergunta que lhe foi feita pelas classes de negocio. Se a tecnologia mudar eu crio um DAO com as consultas XQuery dentro dele e o repositório nunca saberá a diferença.

São duas responsabilidades diferentes. Ser o ponto de encontro das instancias das entidades - Repository, ou ser o cara que garimpa os dados avulsos que constituem essas entidades - DAO.

-----

Alguem falou que um DAO generico seria algo como

Na realidade o DAO mais genérico é

Que é o que o EntityManager do EJB 3 usa , embora ele seja um Repository e não um DAO.

pcalcado wrote:
Segundo este pensamento dá na mesma fazer Action chamar DAO, ou nem ter DAO, afinal dá tudo na mesma. Ou melhoir: pra que interfaces? Use logo as implementações, dá na mesma.

Não, não dá. Se vale a pena usar no caso X ou não é outro assunto, mas pela enésima vez: DAO pode ser a implementação de repositório, repositório não precisa ser implementado por um DAO.

Peraí cara.

Eu digo que dá na mesma pois você mesmo disse que a unica diferença entre uma interface UserDAO e UserRepository é o nome! Por isso da na mesma, das duas maneiras eu abstraio o código de persistência da minha lógica de negócios. Só o nome da interface vai ser diferente.

Não tem nada haver com a ACtion chamar o DAO ou nem mesmo ter o DAO, pois nisso há o grave problema de uma clara violação de camadas.

Virtual Machine Man Membro desde: 04/12/2002 16:26:48 Mensagens: 551 Offline

Pessoal,

Muito boa a discussão. Tenho uma pequena dúvida. Imagine uma classe do dominio do problema. Esta classe (um POJO com atributos e métodos de negócio) não é uma classe "gerenciada" por um container IOC correto (ex: Spring)? Então imagine que necessito de fazer algo do tipo:

E que meu metodo businessMethod precise de uma referência do repositorio para realizar a logica usando tb os atributos preenchidos anteriormente. A pergunta é: como o objeto que implementa o repositório pode ser injetado/atribuido visto que a classe DomainObject não é uma classe gerenciada.
Já pensei em três maneiras:
- AOP: no new eu faria essas injeções. Não sei me parece um overkill... Acho que alguém me disse que o Rod Johnson faz assim... BTW, não gosto muito pois o código não fica muito evidente... mas é uma alternativa
- usar uma Factory ao invés de fazer o new, onde terei oportunidade de injetar os repositórios. Muito manual, um objeto "artificial" à mais, eu sei... Mas é a alternativa que mais me atrai...
- recuperar o repositorio antes e atribui-lo como mais um atributo da minha classe (ARGH!).

Existem mais maneiras? Qual é a mais recomendada? Como vocês estão fazendo isso hoje?

Desde já agradeço a atenção!

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