Dao

Olá pessoal,

Sempre devemos optar por usar DAO genérico?? Correto isso ou não?

Vlws!

Olá,

Nem sempre, muitas vezes você precisa fazer um tratamento antes das operações comuns, como insert, update e delete. Nesse caso você não consegue usar o “DAO Genérico”, mas utilizar o DAO em si já é questão de escolher um Design Pattern, que eu acredito ser bastante utilizado por muitas pessoas atualmente, apesar de existerem outras alternativas como o Repository e Active Record, cada um com suas características próprias.

Não necessariamente isso depende, se você vai fazer ou não a opção por este Design Pattern.

Eu lhe aconselho dar uma lida sobre Design Patter. Na casa do código tem um livro
legal sobre o assunto:

Segue link

Eu não utilizo DAO á muito tempo. Utilizo Repository

Obrigado pelas respostas pessoal.

Acho que vou comprar esse livro sim joaoabi, no momento estou fazendo um trabalho então estou sem muito tempo pra parar e estudar bastante sobre o assunto.

x@ndy, por que não usa mais DAO???
Pergunto pra saber sua opinião mesmo, não tenho muita experiência com Patterns, é bom ver os comentários.

Gostaria de aproveitar o tópico e fazer outra pergunta… estou utilizando o Tomcat.
O ideal é que se use filtros na aplicação?
isso é comum?
Ou, não necessariamente??
Ou só se aplica a quem usa um servidor de aplicação(como Glassfish por exemplo)??

Valeu

O Sérgio Taborda fala bem sobre isso aqui

Se vai usar DAO o ideal é que use o genérico e herde cada um especificando o que queria…

mas de um MODO GERAL deve usar o genérico…

Muita gente usa DAO e Repository como sinonimos. Para mim, a criação do pattern “Repository” para contrapor o DAO me parece mais marketing do que realmente uma necessidade de fato. A motivação original do DAO era justamente encapsular o mecanismo de persistência, exatamente o que faz o Repository. Inclusive, bons DAOs são indistinguíveis de um Repository.

O problema é que muita gente fazia DAOs com cara de objetos do BD. O que, no fundo, abstraía apenas de qual BD vc estava persistindo e não do mecanismo de persistência em si.

[quote=ViniGodoy]Muita gente usa DAO e Repository como sinonimos. Para mim, a criação do pattern “Repository” para contrapor o DAO me parece mais marketing do que realmente uma necessidade de fato. A motivação original do DAO era justamente encapsular o mecanismo de persistência, exatamente o que faz o Repository. Inclusive, bons DAOs são indistinguíveis de um Repository.

O problema é que muita gente fazia DAOs com cara de objetos do BD. O que, no fundo, abstraía apenas de qual BD vc estava persistindo e não do mecanismo de persistência em si.[/quote]

Na verdade são padrões distintos. Com JPA um DAO, se parece muito com um Repository. Como você disse no seu fundamento o DAO encapsulava o mecanismo de persistência, mas o repository não. Na verdade ele utilizava um Domain Store para isso, que hoje pode ser resumido com um EntityManager. O Repository se for implementado com um Domain Store é independente do sistema de persitência tambem. O Domain Store por sua vez podia utilizar um DAO!

Outra colocação é que um Respositório faz parte do modelo de dominio da aplicação um DAO não. Se for colocar isso em camadas DAO ficaria na camada de persistência já o Repository ficaria na camada do dominio.

Outra diferença é que um DAO era um padrão J2EE utilizado pelos BO e TO, Já o repository é um padrão utilizado em com um Domain Model. A primeira referencia a esse padrão eu encontrei no livro do Martim Fowler, Padrões de Arquitetura de Aplicações Corporativas. Esse livro enumera padrões que vão contra o EJB 2.0, que cria o DAO

Com a morte dos BOs e TOs com o java a introdução do EJB 3.0 o DAO acabou perdendo o sentido mas como o pessoal estava acostumado com ele, ele acabou assumindo papeis do repositório. Mas como tem histórias diferentes e papeis diferentes acho importante separar um de outro.

O correto então é que o Repository seja apenas para Buscar dados, e não ter todos os métodos de um CRUD??

Não, ele pode ter os métodos também. Mas você pode criar um repositório somente para pesquisa dos dados! Um Repository não precisa estar necessariamente associado a uma entidade.

Só pra ver se entendi…

Então eu poderia ter um, por exemplo, Usuario_CUD_Repository com as operações do CRUD(C, U e D)…

E outro Usuario_R_Repository com tantas quantas buscas existir??

[quote=jgsilva]Só pra ver se entendi…

Então eu poderia ter um, por exemplo, Usuario_CUD_Repository com as operações do CRUD(C, U e D)…

E outro Usuario_R_Repository com tantas quantas buscas existir??[/quote]

Poder pode, mas seria no mínimo estranho! Por que você faria isso?

É só dúvida mesmo acho que não entendi direito.

Se não for pedir de mais, teria um exemplo de classe Repository pra postar ai?