Comentários sobre: Vale a pena abstrair? – Parte 2 http://blog.michaelnascimento.com.br/2006/09/22/vale-a-pena-abstrair-parte-2/ Michael Nascimento Santos em pt-BR Mon, 13 Apr 2015 12:20:08 +0000 hourly 1 http://wordpress.org/?v=3.0.1 Por: blog.caelum.com.br » Design Patterns: um mau sinal? http://blog.michaelnascimento.com.br/2006/09/22/vale-a-pena-abstrair-parte-2/#comment-292 blog.caelum.com.br » Design Patterns: um mau sinal? Mon, 18 Dec 2006 05:31:57 +0000 http://blog.michaelnascimento.com.br/2006/09/22/vale-a-pena-abstrair-parte-2/#comment-292 [...] Obviamente não estou pregando a total extinção de todos esses patterns (muito menos o DAO!), apenas lembrando que devemos medir muito bem a necessidade de criar mais classes e mais abstrações, em vez de atacar o problema com mais simplicidade, como o Michael Nascimento também já blogou (duas vezes). [...] [...] Obviamente não estou pregando a total extinção de todos esses patterns (muito menos o DAO!), apenas lembrando que devemos medir muito bem a necessidade de criar mais classes e mais abstrações, em vez de atacar o problema com mais simplicidade, como o Michael Nascimento também já blogou (duas vezes). [...]

]]> Por: Ramon Chiara http://blog.michaelnascimento.com.br/2006/09/22/vale-a-pena-abstrair-parte-2/#comment-154 Ramon Chiara Tue, 14 Nov 2006 11:35:56 +0000 http://blog.michaelnascimento.com.br/2006/09/22/vale-a-pena-abstrair-parte-2/#comment-154 Creio que o que vc já disse no 1o post é certo! Não seja arquiteto/programador vidente, KISS, etc. etc. etc... :-) No entanto faltou o ponto mais importante disso tudo: como vc vai saber que sua aplicação precisa ou não de separação das interfaces? Veja, não só DAO, mas qquer uma (bom, vc já tinha dito isso rsrs) Nisso o TDD (independentemente de XP) ajuda! Se vc ir montando o teste, programando do jeito que vc quer que a coisa funcione, a arquitetura vai surgindo de uma forma muito bacana, onde será testável e simples. Provavelmente só vai surgir o DAO quando vc precisar mesmo. Lógico que tudo isso requer prática e experiência, como tudo na vida ;-) []s PS: não estou aqui pregando TDD, hein! :-) Só estou dizendo que é uma opção para que vc descubra em que pontos sua aplicação vai precisar de separação das interfaces! Creio que o que vc já disse no 1o post é certo!
Não seja arquiteto/programador vidente, KISS, etc. etc. etc… :-)
No entanto faltou o ponto mais importante disso tudo: como vc vai saber que sua aplicação precisa ou não de separação das interfaces? Veja, não só DAO, mas qquer uma (bom, vc já tinha dito isso rsrs)
Nisso o TDD (independentemente de XP) ajuda!
Se vc ir montando o teste, programando do jeito que vc quer que a coisa funcione, a arquitetura vai surgindo de uma forma muito bacana, onde será testável e simples. Provavelmente só vai surgir o DAO quando vc precisar mesmo. Lógico que tudo isso requer prática e experiência, como tudo na vida ;-)
[]s
PS: não estou aqui pregando TDD, hein! :-) Só estou dizendo que é uma opção para que vc descubra em que pontos sua aplicação vai precisar de separação das interfaces!

]]> Por: Thiago R S http://blog.michaelnascimento.com.br/2006/09/22/vale-a-pena-abstrair-parte-2/#comment-94 Thiago R S Tue, 26 Sep 2006 17:02:58 +0000 http://blog.michaelnascimento.com.br/2006/09/22/vale-a-pena-abstrair-parte-2/#comment-94 Olá, muito interessante estes posts sobre abstração de DAO's. Quero dizer que estou com vocês. A máxima abstração que costumo chegar é criar uma interface para o DAO e sua respectiva implementação. Isso quando devo usar DAO's. Para o restante dos casos, estou evitando o pattern discutido. Prefiro colocar logo o hibernateTemplate (Spring) ou EntityManager (JPA) na minha camada de serviço. Depois garanto se tudo funca com um teste de integração. Testes unitários apenas em trechos que exigem uma atenção especial. Também tenho pouco interesse por DAO's genéricos, mas isso é questão de gosto. Abraços Thiago Olá,

muito interessante estes posts sobre abstração de DAO’s. Quero dizer que estou com vocês. A máxima abstração que costumo chegar é criar uma interface para o DAO e sua respectiva implementação. Isso quando devo usar DAO’s.

Para o restante dos casos, estou evitando o pattern discutido. Prefiro colocar logo o hibernateTemplate (Spring) ou EntityManager (JPA) na minha camada de serviço. Depois garanto se tudo funca com um teste de integração. Testes unitários apenas em trechos que exigem uma atenção especial.

Também tenho pouco interesse por DAO’s genéricos, mas isso é questão de gosto.

Abraços
Thiago

]]> Por: Paulo Silveira http://blog.michaelnascimento.com.br/2006/09/22/vale-a-pena-abstrair-parte-2/#comment-91 Paulo Silveira Tue, 26 Sep 2006 03:00:58 +0000 http://blog.michaelnascimento.com.br/2006/09/22/vale-a-pena-abstrair-parte-2/#comment-91 "Por exemplo, em projetos que usam DAO extensivamente, já vi várias vezes classes de negócio que simplesmente delegavam para os DAOs, sem adicionar lógica nenhuma..." - eu vejo isso _sempre_, dia e noite! mais ainda, antes da classe de negócio tem de passar por uns 3 delegates diferentes, todos interfaceados... “Por exemplo, em projetos que usam DAO extensivamente, já vi várias vezes classes de negócio que simplesmente delegavam para os DAOs, sem adicionar lógica nenhuma…” – eu vejo isso _sempre_, dia e noite! mais ainda, antes da classe de negócio tem de passar por uns 3 delegates diferentes, todos interfaceados…

]]>