Do ponto de vista do S do SOLID - Single Responsiblity Principle, não seria melhor criar um service para cada endpoint do controller?
Por exemplo, um service para cada item do CRUD.
Você está vendo a versão anterior da nova experiência da Alura que estamos preparando para você. Em breve, ela ganha uma identidade visual novinha totalmente pensada em potencializar seus estudos!
Do ponto de vista do S do SOLID - Single Responsiblity Principle, não seria melhor criar um service para cada endpoint do controller?
Por exemplo, um service para cada item do CRUD.
Olá, Rodrigo! Tudo bem?
Compreendo sua dúvida e acho que ela é muito relevante! O princípio da Responsabilidade Única (Single Responsibility Principle - SRP) do SOLID é uma diretriz importante para manter nosso código organizado e manutenível.
No entanto, a aplicação do SRP não significa necessariamente que devemos ter um serviço para cada endpoint do controller. Na verdade, o SRP sugere que uma classe deve ter apenas um motivo para mudar, ou seja, deve ter apenas uma responsabilidade.
No contexto da nossa API Java, um serviço geralmente é responsável por um domínio específico do nosso aplicativo. No exemplo da aula, temos o PetService e o AbrigoService. O PetService é responsável por todas as operações relacionadas a pets, enquanto o AbrigoService é responsável por todas as operações relacionadas a abrigos.
Se seguíssemos a ideia de ter um serviço para cada endpoint, poderíamos acabar com uma quantidade excessiva de classes, o que pode tornar o código mais difícil de gerenciar e entender. Além disso, poderíamos ter muita duplicação de código, já que vários endpoints podem compartilhar a mesma lógica.
Por exemplo, se tivéssemos um PetCreateService, PetReadService, PetUpdateService e PetDeleteService, todos esses serviços provavelmente precisariam interagir com o PetRepository. Isso significaria que teríamos que injetar o PetRepository em todos esses serviços, o que é uma duplicação desnecessária.
Em vez disso, podemos ter um único PetService que encapsula toda a lógica relacionada a pets. Esse serviço pode ter métodos como createPet, getPet, updatePet e deletePet, cada um correspondendo a um endpoint específico do PetController. Dessa forma, mantemos nosso código DRY (Don't Repeat Yourself), fácil de entender e manter.
Espero ter ajudado e bons estudos!