DAO's nas classes de negócio

Uma vez, batendo papo com o Vinícius Siegel (dono da global code) num evento , estávamos falando sobre pattern e ele falou uma coisa muito interessante : "Depois de 2 ou 3 cervejas, eles são praticamente iguais ...

".

Brincadeira à parte, costumo fazer o design dessa camada utilizando uma interface DAO e sua implementação de modo genérico.

Na camada Business, IoC desse com a "ajudinha" do Spring ou um esquema de anotações que voê pode montar tb ...

PS: vou postar um artigo sobre isso no meu blog, que não atualizo a quase um ano

pcalcado wrote:
1) Nomes são muito importantes. Design Patterns são úteis entre outras coisas por definirem um nome comum a alguma técnicas, por isso nomenclatura deve ser usada com muito cuidado.

2) Um Repositório não é um DAO, um DAO pode ser um repositório.

Legal Phillip. Realmente usar o nome Repository e usar a nomenclatura de métodos sugerida pelo Fábio Kung fica menos na cara que ta usando um banco de dados por trás, fica mais bonito, etc.

Mas acho que o pessoal ta mais acostumado com o termo DAO e, no fim, DAO e Repository acaba tendo o mesmo efeito.

microfilo wrote:
Mas acho que o pessoal ta mais acostumado com o termo DAO e, no fim, DAO e Repository acaba tendo o mesmo efeito.

Ou eu não tô sabendo explicar ou tem algo errado na comunicação...

Imagine a situação: o seu DAO recebe como parâmetro um HttpRequest. Tem o mesmo efeito que passar um objeto de negócios para ele, não?

RafaelRio wrote:por todos os motivos já citados, a interface UserDAO deve ser renomeada para UserRepository.

Então, o artigo Ei! Como é o seu DAO? Ele é tão abstraído quanto o meu? do blog da Caelum deve ser atualizado, certo?

Não necessariamente. (1)Ele não precisa estar falando de DDD e (2) ainda que você adote a estratégia simplificada de DAO<<implements>>Repository nada impede que o DAO tenha sua própria interface para promover alguma abstração.

Fabio Kung wrote:Se os objetos do domínio possuírem alguma referência, eu chamaria a interface de Repository, caso contrário chamaria de DAO.

É beeeeeem por aí. Um repository é como *objetos de negocio* enxergam 'o lugar onde objetos sao guardados'. Se eles sao guardados num SGBD e mapeados com um DAO nao importa aos objetos de negocio.

Boa Phillip, foi exatamente o que eu quis dizer!

No artigo do Paulo lá no blog da Caelum, o DAO não está sendo usado dentro dos objetos do domínio, por isso continua sendo DAO.

A diferença é sutil:

getProdutos passando 'this' ficou BEM feio, mas é só para ilustrar a idéia.

Thread.start() Membro desde: 16/09/2006 11:16:01 Mensagens: 45 Offline

Entao depois de tanta teoria como ficaria uma estrutura web para acessar um
banco de dados por exemplo?

view -> action -> modelo de negocios -> UserRepository(Interface) -> UserDao(implementação) -> etc etc..

??

Se eu entendi direito:

req HTTP -> Action -> Modelo -> UserRepository -> Implementação concreta do repositário MySQLUserRepository -> Banco de dados.

Mas acho que eu entendi errado, pois acima só trocamos o nome DAO por Repository.

Então talvez seja algo assim:

req HTTP -> Action -> Modelo -> UserRepository -> Implementação concreta de UserRepository -> User DAO -> Implementação concreta de UserDAO -> Banco de dados.

Parece correto do ponto de vista teórico, mas com o side-effect prático de termos muitas classes e interfaces.

Minha dúvida agora já é outra. Acredito que devido a simplicidade do meu modelo de negócios ele acabou se comportando como um UserRepository apenas, ou seja, sua única função ficou sendo CRUD de beans.

Acho que esse conceito está difícil de assimilar porque em muitos casos o repositório vai apenas espelhar fielmente o DAO, logo ele parece uma camada a mais apenas com sentido teórico mas nao prático.

Por exemplo, se eu precisar pegar todos os usuários maiores de X anos, com a cueca da cor Y e cadastrados antes de 1990, terei que criar um novo método no repositorio e um outro igualzinho no DAO.

Haverá muita duplicação entre o DAO e o Repository... A dúvida que ficou e se isso tem que ser usado sempre ou não, depende do caso.

O outro extremo seria colocar tudo na action, ou seja, a action -> DAO -> banco...

Todas essas camadas (Repository -> RepositoryImpl -> DAO -> DAOImpl) são a maior abstração possível. Você não precisa (eu eu acho que nem deve) fazer isso sempre. Se for só para ter um monte de interfaces e classes ocas que só delegam tudo, eu não acho que valha a pena abstrair.

Já foi o tempo que achava melhor interfacear e abstrair tudo. Até discutia bastante sobre isso com o Michael Nascimento e com o Paulo Silveira (aqui e aqui).

Hoje em dia eu mudei minha opinião e procuro sempre manter as coisas o mais simples possível, mas isso não significa fazer errado (acabar com a OO, por exemplo). O Repository não precisa ser apenas um envelope para o dao. Nem interfacear o repositório é obrigatório e regra geral.

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.

O conceito do Repository é esse que o Phillip apresentou (e o trecho de código que eu postei). Já como implementá-lo, no meu ponto de vista, vai depender de cada caso.

Kenobi wrote:Vinícius Siegel (dono da global code) ...

Vinícius Senger né?

(ou ele tem um sobrenome que ninguém conhece?)

saoj wrote:Então talvez seja algo assim:

req HTTP -> Action -> Modelo -> UserRepository -> Implementação concreta de UserRepository -> User DAO -> Implementação concreta de UserDAO -> Banco de dados.

Parece correto do ponto de vista teórico, mas com o side-effect prático de termos muitas classes e interfaces.

[. . .]

Acho que esse conceito está difícil de assimilar porque em muitos casos o repositório vai apenas espelhar fielmente o DAO, logo ele parece uma camada a mais apenas com sentido teórico mas nao prático.

Penso assim também.

saoj wrote:Por exemplo, se eu precisar pegar todos os usuários maiores de X anos, com a cueca da cor Y e cadastrados antes de 1990, terei que criar um novo método no repositorio e um outro igualzinho no DAO.

saoj, pelo que andei pesquisando, esse é o tipo de operação sob responsabilidade de um repository, que internamente utilizaria um DAO para acessar os dados necessários e então fazer o processamento e devolver o resultado ao cliente.

Os DAO's seriam escondidos e ficariam com o mais simples e puro CRUD; operações mais relacionadas com o negócio sobem para o repository.

Fabio Kung wrote:Todas essas camadas (Repository -> RepositoryImpl -> DAO -> DAOImpl) são a maior abstração possível. Você não precisa (eu eu acho que nem deve) fazer isso sempre. Se for só para ter um monte de interfaces e classes ocas que só delegam tudo, eu não acho que valha a pena abstrair.

Já foi o tempo que achava melhor interfacear e abstrair tudo. Até discutia bastante sobre isso com o Michael Nascimento e com o Paulo Silveira (aqui e aqui).

Assino em baixo. E vale a pena ver essa discussão.

Hoje em dia eu mudei minha opinião e procuro sempre manter as coisas o mais simples possível, mas isso não significa fazer errado (acabar com a OO, por exemplo). O Repository não precisa ser apenas um envelope para o dao. Nem interfacear o repositório é obrigatório e regra geral.

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.

Mesmo porque, dizer o contrário é ir contra um dos princípios do XP, metodologia que parece ser seguida por vários profissionais no GUJ.

Eu achei o conceito de Repository interessante, mas não vi ganhos nem mesmo em grandes projetos. No meu caso, por exemplo, teria que fazer muito mais do que renomear algumas interfaces.

Se um dia eu achar útil... Bem, para isso que serve refactoring.

Fabio Kung wrote:

Kenobi wrote:Vinícius Siegel (dono da global code) ...

Vinícius Senger né?

(ou ele tem um sobrenome que ninguém conhece?)

Boa ... eu realmente me confundi, não sei pq troquei o sobrenome do cara

Obrigado

RafaelRio wrote:mas não vi ganhos nem mesmo em grandes projetos

Rafael, o ganho seria justamente deixar a coisa mais OO.
Em vez de:

Você consegue fazer:

Se o fornecedor tiver uma referência para o RepositorioDeContas (ContasRepository).

Fabio Kung wrote:

RafaelRio wrote:mas não vi ganhos nem mesmo em grandes projetos

Rafael, o ganho seria justamente deixar a coisa mais OO.

Kung, você sabe, para calcular ganhos é preciso conhecer vantagens e desvantagens - me corrigindo, a palavra mais correta seria "valor", ao invés de "ganhos".

A questão que eu coloquei é "essa camada a mais vale a pena"? Se o preço para mais uma camada superar os ganhos de tornar "a coisa mais OO", a resposta é não. Taí uma discussão que vai (ou melhor, poderia ir) longe...

Ultimamente tenho pensado que vale a pena questionar novas teorias que andam ululando por aí, em pró da simplicidade, desde que com fundamentos, ao invés de simplesmente aceitá-las.

Esse repository, por exemplo, vocês podem argumentar que torna as coisas mais claras, elegantes, o genro que toda sogra gostaria de ter, mais OO, etc. Mas tô sentindo que a reação da maioria das pessoas será "isso é lindo na teoria, mas não na prática; deixa quieto, vou continuar com meus DAO's". Vão deixar (aproveitando esse exemplo) o Repository para uma "zelite" que irá se formar - "isso é só pros caras".

E quando argumentos do tipo "torna a coisa mais OO", "segundo Fowler", etc, finalmente se desgastarem, essa elite ficará isolada numa torre de marfim - já aconteceu e acontece em diversas áreas. Vão dizer coisas lá de cima na torre, as pessoas vão escutar, ficar encantadas, vai entrar por um ouvido e sair pelo outro.

Isso vai formar um vazio, que será preenchido por palpiteiros inconseqüentes, que pregarão contra a OO, design patterns e o inglês e arrebatarão coraçãozinhos por adotarem uma aura de pragmáticos (levanta a mão quem não sabe do que estou falando).

Não me entendam mal, não estou soando as trombetas do apocalipse e sou fã da fundamentação e da boa literatura. Mas tudo tem limites, cada caso é um caso, teoria ainda é uma teoria, devem ser testadas na prática, por aí vai. (Uauu!! Isso é que bom uso de clichês...)

Aceitam uma sugestão? Em casos assim, penso que o ideal seria escrever artigos técnicos com o contexto e os pormenores, como a série sobre exceções do Luca e o artigo sobre DTO do shoes. Um já é referência no tema, o outro, aposto, vai virar.

A partir daí, as pessoas pensam e decidem com suas cabeças qual o melhor caminho.

Abraços!

Fabio Kung wrote:

RafaelRio wrote:mas não vi ganhos nem mesmo em grandes projetos

Rafael, o ganho seria justamente deixar a coisa mais OO.
Em vez de:
Fornecedor fornecedor = ...; List<Conta> contas = dao.carregaContasPagasDesde1999(fornecedor);
Você consegue fazer:
Fornecedor fornecedor = ...; List<Conta> contas = fornecedor.getContasPagasDesde1999()
Se o fornecedor tiver uma referência para o RepositorioDeContas (ContasRepository).

É realmente, o segundo é bem melhor que o primeiro, e temo que eu esteja inclinado a fazer o primeiro. Mas isso não tem haver com a questão do repository x DAO. Seja com DAO dentro de forncedores ou com repository dentro de forncedores talvez a coisa deva ser sempre feita assim mesmo como o Fábio falou... É para pensar e brincar...

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