31 messages in net.java.dev.cejug.discussao[CEJUG] Re: DAO generico vale a pena?| From | Sent On | Attachments |
|---|---|---|
| Jean Jorge Michel | Jun 7, 2011 5:59 pm | |
| Leandro Costa | Jun 7, 2011 6:05 pm | |
| Rafael Santiago | Jun 7, 2011 9:19 pm | |
| Leonardo Ruoso | Jun 8, 2011 3:29 am | |
| Leonardo Ruoso | Jun 8, 2011 3:40 am | |
| Wendel Cabral | Jun 8, 2011 4:20 am | |
| Hildeberto Mendonça | Jun 8, 2011 4:22 am | |
| Leandro Costa | Jun 8, 2011 4:35 am | |
| Hildeberto Mendonça | Jun 8, 2011 4:47 am | |
| Assis Júnior | Jun 8, 2011 4:50 am | |
| Leandro Costa | Jun 8, 2011 4:52 am | |
| Jean Jorge Michel | Jun 8, 2011 5:00 am | |
| Jean Jorge Michel | Jun 8, 2011 5:12 am | |
| Petit xD | Jun 8, 2011 5:18 am | |
| Rafael Ponte | Jun 8, 2011 5:19 am | |
| Rafael Ponte | Jun 8, 2011 5:24 am | |
| Hildeberto Mendonça | Jun 8, 2011 5:34 am | |
| Julio Viegas | Jun 8, 2011 5:41 am | |
| Guilherme Bahia | Jun 8, 2011 5:49 am |  .gif |
| Jean Jorge Michel | Jun 8, 2011 5:52 am | |
| Jean Jorge Michel | Jun 8, 2011 6:03 am | |
| Assis Júnior | Jun 8, 2011 10:09 am | |
| Jean Jorge Michel | Jun 10, 2011 9:15 am | |
| Leonardo Ruoso | Jun 10, 2011 10:32 am | |
| Leonardo Ruoso | Jun 10, 2011 10:36 am | |
| Mesias | Jun 10, 2011 12:16 pm | |
| Leonardo Ruoso | Jun 10, 2011 12:34 pm | |
| Assis Júnior | Jun 10, 2011 2:01 pm | |
| Assis Júnior | Jun 10, 2011 2:03 pm | |
| Ivan Aguirre | Jun 10, 2011 4:44 pm | |
| Jose Moises | Jun 10, 2011 6:32 pm |
| Subject: | [CEJUG] Re: DAO generico vale a pena? | |
|---|---|---|
| From: | Assis Júnior (assi...@gmail.com) | |
| Date: | Jun 8, 2011 10:09:19 am | |
| List: | net.java.dev.cejug.discussao | |
O Júlio Viegas falou muito bem, acima.
Complementando:
1. Faça um código simples e com testes automatizados. 2. Refatore constantemente. 3. Os padrões de projeto aparecerão sem você se preocupar. Caso veja que um padrão se encaixa melhor que outro na solução refatore e teste. 4. Se você ainda acha que algo *deve *mudar, refatore e teste mais um pouco. 5. No final seu código deverá ser o mais adaptado a sua situação.
Cada caso é um caso. Os padrões devem ser usados para resolver problemas
reais e cada padrão tem seu modo de uso. Usar um padrão em um local não
adequado traz
'cheiros<http://books.google.com.br/books?id=zPdb4QJKBtkC&pg=PA70&lpg=PA70&dq=martin+fowler+cheiros&source=bl&ots=e2q9sinoh3&sig=874ghKWA35oFnuZGd5122MkL8KQ&hl=pt-BR&ei=t6vvTdzwMYnrgQfXtMGUDw&sa=X&oi=book_result&ct=result&resnum=2&ved=0CCEQ6AEwAQ#v=onepage&q=martin%20fowler%20cheiros&f=false>'
que podem indicar onde melhorar/refatorar.
A dica acima do Rafael Ponte sobre testes é muito útil. Em se tratando de
software testes automatizados e refactor constantes são o melhor
investimento.
Em 8 de junho de 2011 09:42, Julio Viegas <juli...@julioviegas.com>escreveu:
Como "regra", costumo usar interfaces para os casos onde ha mais de uma origem de dados. E sao raros.
Eu procuro trabalhar com "design emergente" em situacoes onde nao ha boa compreensao do problema, ou seja, abstrair/compor apenas quando ha mais de uma situacao semelhante. Eh possivel aplicar herança nesses casos via refactoring, ou seja, vc pode descobrir comportamentos em comum que podem ser centralizados em uma classe pai apos repetir uma mesma situacao. O risco disso eh amarrar seu desenho a um padrao que nem sempre vai atender todos os casos(filhos). Quanto maior a quantidade de especializacoes de uma mesma classe, mais esse problema pode se tornar visivel. Heranca cobra o preco de vc especificar um desenho e comportamento padrao que atenda todas as classes herdadas.
Se vc nao tem uma boa visao do seu problema, use design emergente. O preco disso eh ter que alterar o desenho ao decorrer da implementacao, o que nao eh ruim. Senao, use o design first.
O mais importante antes de tudo: entenda bem seu problema e qual o nivel seguro de suposicoes vc pode assumir ao desenhar e implementar o comportamento do seu codigo.
Enfim, minha resposta estah no primeiro paragrafo... :)
Abs, JV -- julioviegas.com
2011/6/8 Rafael Ponte <rpo...@gmail.com>:
Se tua aplicação possui muitos CRUDs a serem desenvolvidos provavelmente o uso de um DAO generico ajude, ou melhor, se você estiver utilizando JPA/Hibernate provavelmente o uso de um Service generico (ou qualquer outro nome que você queira dar) é uma opção mais apropriada. Vale salientar que um DAO generico só te ajudará para os casos de CRUDs, qualquer outro caso eu nem me arriscaria a estender/implementar algo generico.
Independente de você utilizar DAO/Service generico ou não, dedique um esforço para os testes automatizados, com certeza eles agregarão mais valor do que chegar a solução ideal para um componente generico de CRUD :-)
No mais, tome cuidado com o excesso de DAOs na tua aplicação! 2011/6/7 Jean Jorge Michel <jean...@gmail.com>
Boa noite pessoal. Queria saber dos amigos se vcs acham vantagem ter um DAO generico ao invés de DAOs para casa classe do sistema. Deixa eu ver se me faço entender. Hoje estou vendo um sistema onde TUDO é genérico. Ok, pode ser válido. Mas ai vem aquela pergunta: e o ovo, veio antes ou depois da galinha? Quando temos um DAO genérico e queremos algumas ações específicas para uma classe? Aqui foi feito um DAO para a classe X que estende o genérico e tal.... mas quase toda a classe tem sua peculiaridade, então são muitos DAOs estendendo o genérico. A Caelum no seu blog fala em interfaces para restringir o DAO genérico. Aí teremos um uma interface do DAO genérico > a implementação do DAO genérico > a Interface de restrição > o DAO que estende o genérico e implementa a interface. Ufa. Se eu vou ter isso para 30 classes eu posso economizar 30 interfaces não tendo esse DAO genérico. Queria o conselho, a experiência dos amigos sobre o assunto. Pela atenção obrigado.
-- Best regards, Jean J. Michel
* Sent from my cellphone, please forgive the lack of accents and punctuation marks ;) My blogs: http://www.jeanjmichel.blogspot.com and http://www.anonymousbiker.wordpress.com My Twitter: http://twitter.com/jeanjmichel
-- Rafael Ponte http://www.rponte.com.br
-- Atenciosamente, Assis júnior SCJP 5.0 Certified