Eu descobri que o JPA, ou algo semelhante, não encoraja o padrão DAO

Eu descobri que o JPA, ou algo semelhante, não encoraja o padrão DAO. Eu não sei, mas me sinto assim, especialmente com gerenciadores de JTA gerenciados pelo servidor.

Após um hands-on adequado usando o padrão DAO, comecei a projetar aplicativos baseados em JPA em torno desse padrão. Mas não se encheckbox, IMO. Eu costumo perder alguns resources do JPA e tudo.

Bem, suponha que você ative uma consulta com bloqueio pessimista e retornou uma lista de inputs de um método DAO. Ao retornar, a transação é encerrada e o bloqueio é eliminado (um caso com o gerenciador JTA gerenciado pelo servidor). Então, não adianta, vagamente falando. Existem casos válidos, no entanto.

Outro exemplo é muito mais trivial. Suponha que você dispare uma consulta para obter alguma entidade, que tenha uma associação lenta de um para muitos com outra entidade. Ao retornar o método DAO, a transação é finalizada. O carregamento preguiçoso não funcionaria mais, você simplesmente obtém null ou algo assim. Para lidar com isso, nós o carregamos avidamente manualmente. nós fazemos algo como a.getBList().size() .

Assim, IMO é melhor não fazer um DAO exclusivamente, e fazê-lo em seu bean de negócios, desta forma você será capaz de tirar proveito desses resources úteis. Ou ORM API pode ser considerada uma DAO / camada de dados em si, sem dúvida. Então, não precisamos fazer outro.

O que vocês pensam sobre isso?

Nota: Eu não digo, por qualquer meio, que o padrão DAO é obsoleto. De fato, isso depende de caso a caso.

Para aplicativos simples, não vejo nenhum problema em usar o EntityManager diretamente dos EJBs e pular o padrão DAO (estou cansado de escrever muito código). E meu sentimento é de fato que isso é o que a JPA e a API Java EE incentivam. Mas ainda pode ser justificado para aplicações mais complexas (para access a dados a partir de stored procedures, arquivos simples …). Então você está certo, isso depende 🙂

Você encontrará algum outro ponto de vista esclarecido no Has JPA Killed the DAO? no InfoQ, mas você não ficará surpreso com o conteúdo ea conclusão que pode ser resumida como: você realmente não precisa mais do padrão DAO para access a dados padrão, mas pode precisar dele para algumas situações mais complexas, mas nós vivemos melhor sem ele.

Se você não definir o próprio DAO para ser transacional, você não terá esses problemas.

A camada de serviço deve ser transacional, porque uma transação deve abranger várias operações. Colocar cada inserção / atualização em uma transação não é o melhor cenário.

Com a primavera você consegue isso com muita facilidade. Sem isso você talvez inclua a lógica de transação em seu DAO novamente – isto é, dao.beginTransaction() e dao.commitTransaction() e use isso da camada de serviço.

Pelo que entendi, você sugere que usar o EntityManager diretamente nas classs de serviço é provavelmente melhor do que ter uma class DAO wrapper. Eu não concordo por um motivo. Trabalhando a class DAO (interface na melhor das hipóteses) em suas classs de serviço, você não tem dependência da API JPA. Você não precisa construir objects de Query ou semelhantes. Isso pode não ser uma grande vantagem, mas você concorda que é uma prática recomendada. E depois você pode alternar para JDBC simples, texto simples, XML ou qualquer outra coisa, alterando apenas o DAO.

Isso, embora amplamente usado como um exemplo de por que você deve abstrair algo em outra camada, é na maioria das vezes simplesmente um superdesign. Mas às vezes o fato de que todas as operações de access ao database estão passando por um único lugar significa que você pode adicionar log, verificações de nível de access etc. (Sim, às vezes o DAO não é uma maneira adequada de fazer isso).

Então, em última análise, para voltar ao seu ponto – isso depende.

O DAO é usado para perspectiva de design, enquanto o JPA é um wrapper “Oficial” para funções de access a dados. Não há como o JPA estar tentando eliminar o DAO – ele pode tornar o DAO mais fácil de implementar, talvez tão fácil que o DAO pareça tão simples que possa ser ignorado. Mas sem a camada DAO, o benefício de design não existe mais.

Claro, para projetos “simples”, pode ser ignorado. Muitas coisas podem ser “ignoradas” se o projeto for “simples” o suficiente.