Camada de serviço vs DAO - Por que ambos?

Eu tenho trabalhado com SpringMVC, Hibernate e alguns bancos de dados em um exemplo de aplicativo da web java.

Existem alguns diferentes que fazem isso, mas este tutorial de integração do Spring 3 e hibernação, por exemplo, tem uma classe model, view (em jsp) e classes service e dao para o controlador.

Minha pergunta é: as classes service e DAO não fazem a mesma coisa? Por que você precisaria dos dois?

Este foi o tutorial que eu estava realmente usando: http://fruzenshtein.com/spring-mvc-security-mysql-hibernate/

Geralmente, o DAO é o mais leve possível e existe apenas para fornecer uma conexão com o banco de dados, às vezes abstraído para que diferentes recursos de banco de dados possam ser usados.

A camada de serviço existe para fornecer lógica para operar nos dados enviados para e do DAO e do cliente. Muitas vezes, essas duas partes são agrupadas no mesmo módulo e, ocasionalmente, no mesmo código, mas você ainda as verá como entidades lógicas distintas.

Outro motivo é a segurança - se você fornecer uma camada de serviço que não tem relação com o banco de dados, será mais difícil obter acesso ao banco de dados pelo cliente, exceto por meio do serviço. Se o banco de dados não puder ser acessado diretamente do cliente (e não houver módulo trivial do DAO atuando como serviço), todo invasor que assumiu o controle do cliente poderá tentar invadir a camada de serviço também antes que ele obtenha tudo, menos o acesso mais higienizado aos seus dados.

Eu sou o escritor do post em questão. Eu tenho o meu quinhão trabalhando em diferentes tecnologias e arquiteturas. Com base no exposto, posso dizer com segurança que ter uma camada de serviço e uma dao é sempre uma boa idéia. O DAO deve ser limitado a apenas adicionar / atualizar / inserir / selecionar objetos de entidade no / do banco de dados e isso é tudo. Se você quiser fazer algo extra em termos de lógica, adicione-o à camada de serviço. Isso ajudará a tornar o código modular e facilmente substituível quando o banco de dados for substituído (para parte de dados). Isso é especialmente aplicável em aplicativos que envolvem relatórios com lógicas pesadas, mesmo após a busca de dados do banco de dados.

Além disso, na primavera, a segurança é aplicada na camada de serviço idealmente. Você não gostaria de mudar dessa maneira.

Adam Bien aponta em seu livro o fato de que o JPA EntityManager é uma boa implementação universal do DAO:

http://realworldpatterns.com/

No mundo Java EE, quase nunca é necessário escrever seu próprio DAO, porque as implementações de JPA incluem uma. Você só precisa escrever a camada de serviço.

A implementação de sua própria camada DAO é realmente uma ressaca da muito pobre arquitetura J2EE de 15 anos atrás, mas muitas pessoas ainda se sentem compelidas a fazê-lo. Essas camadas DAO personalizadas geralmente fornecem nada além de funções de encaminhamento que chamam o método correspondente no EntityManager.

Portanto, para responder à sua pergunta, sim, você precisa de uma camada de serviço e de um DAO, mas precisa apenas escrever a camada de serviço.

Normalmente, coloco todo o código específico do banco de dados (consultas) nos DAO, manipulação de transações e lógica de negócios nos serviços. Isso permite que os métodos de serviço invoquem métodos em vários dao's e mantenham tudo dentro da mesma transação. Na minha opinião, isso permite uma melhor reutilização de código entre os dao.

Eu descobri que a camada de serviço adiciona complexidade desnecessária na maioria dos casos. Em teoria, é evitar ter lógica de negócios na camada dao, mas, no final, isso apenas gera confusão, mesmo algumas pessoas desusaram de remover completamente a camada dao, porque acham que isso não agrega valor. http://ayende.com/blog/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer

Mas se você tiver várias lógicas de negócios, então sim. É uma boa ideia. Quão essencial é criar uma camada de serviço?

IMHO a camada de Serviço pode ser considerada como uma camada entre o controlador e a camada DAO. Essa camada de serviço é exatamente onde podemos adicionar lógica de negócios e até criar um objeto de retorno específico para o que precisa ser renderizado pela exibição.