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

Geralmente, o DAO é o mais leve possível e existe somente para fornecer uma conexão ao banco de dados, às vezes abstraído, de modo que diferentes back-ends de banco de dados podem ser usados.

A camada de serviço está lá para fornecer lógica para operar nos dados enviados de e para o DAO e o cliente. Muitas vezes, essas duas partes serã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 tenha relação com o banco de dados, será mais difícil obter acesso ao banco de dados do cliente, exceto por meio do serviço. Se o banco de dados não puder ser acessado diretamente do cliente (e não houver um módulo DAO trivial atuando como o serviço), tudo o que um invasor assumiu o cliente é tentar invadir a camada de serviço antes que ele receba tudo, menos o acesso mais higienizado aos seus dados.

Eu sou o autor do post em questão. Eu tenho o meu quinhão de trabalhar em diferentes tecnologias e arquiteturas diferentes. Com base no acima, posso dizer com segurança que ter camada de serviço e camada dao é sempre uma boa ideia. O DAO deve ser limitado apenas para adicionar / update / insert / select objetos Entity 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 alguma parte dos dados). Isso é especialmente aplicável em aplicativos que envolvem relatórios com lógicas pesadas, mesmo depois de buscar dados do banco de dados.

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

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

link

No mundo do Java EE, quase nunca há necessidade de escrever seu próprio DAO, pois as implementações do JPA incluem um. Você só precisa escrever a camada de serviço.

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

Então, para responder à sua pergunta, sim, você precisa de uma camada de serviço e um DAO, mas só precisa escrever a camada de serviço.

Geralmente, coloco todo o código específico do banco de dados (consultas) no DAO e no gerenciamento 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 e mantenham tudo dentro da mesma transação. Na minha opinião, isso permite uma melhor reutilização de código nos dao.

Descobri que a camada de serviço adiciona complexidade desnecessária na maioria dos casos. Em teoria, é para evitar ter lógica de negócios na camada dao, mas no final isso só leva a confusão, até mesmo algumas pessoas se desusaram para remover completamente a camada dao como eles sentem que não agrega valor. link

Mas se você tem várias lógicas de negócios, então sim. É uma boa ideia. Como é 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.