manipulação de objeto Spring MVC Domínio Best Practice
-
21-08-2019 - |
Pergunta
Vamos assumir uma simples Spring MVC controlador que recebe o ID de um objeto de domínio. O Controlador deve chamar um serviço que deveria fazer algo com esse objeto de domínio.
Aonde "convertido" a identificação do objeto de domínio para o objeto de domínio, carregando-o do banco de dados? Isso não deve ser feito pelo controlador. Então a interface método de serviço tem que usar aceitar o ID do objeto de domínio em vez do domínio próprio objeto. Mas a interface do serviço seria melhor se ele leva o objeto de domínio como parâmetro.
Quais são seus pensamentos sobre este caso de uso comum? Como voce resolve isso?
Solução
O controlador deve passar o baixo ID para a camada de serviço e, em seguida, voltar o que for necessário para tornar o resto da resposta HTTP.
Assim -
Map<String,Object> doGet (@RequestParam("id") int id) {
return serviceLayer.getStuffByDomainObjectId(id);
}
Qualquer outra coisa só vai ser poluir a camada web, que não deve se preocupar em tudo sobre persistência. Todo o propósito da camada de serviço é fazer com que objetos de domínio e dizer-lhes para executar sua lógica de negócios. Assim, uma chamada de banco de dados deve residir na camada de serviço como tal -
public Map<String,Object> getStuffByDomainObjectId(int id) {
DomainObject domainObject = dao.getDomainObjectById(id);
domainObject.businessLogicMethod();
return domainObject.map();
}
Outras dicas
em um projeto meu que eu usei a camada de serviço:
class ProductService {
void removeById(long id);
}
Eu acho que isso vai depender de se o serviço é local ou remoto. Como regra geral eu tento passar IDs sempre que possível a serviços remotos, mas preferem objetos para os locais.
O raciocínio por trás disso é que ele reduz o tráfego de rede em apenas enviar o que é absolutamente necessário para serviços remotos e previne várias chamadas para DAOs para serviços locais (embora com Hibernate cache isso pode ser um ponto mute para os serviços locais).