6 erros com Spring Boot que você não deve fazer
ฝัง
- เผยแพร่เมื่อ 10 ก.ย. 2024
- O vídeo apresenta algumas más práticas de desenvolvimento em projetos Spring Boot:
1 - Devolver entidades JPA ao invés de DTOs
2 - Não utilizar princípios de responsabilidade única
3 - Não utilizar exception Handlers
4 - Não utilizar beans validations
5 - Não usar Dependency Injection
6 - Não utilizar Consultas Páginadas com JPA
Acompanhe cada um desses problemas bem com o suas soluções
Mais conteúdos de Spring Boot nessa Playlist:
• Java e Spring Boot
Para acessar o código desse exemplo acesse o link abaixo:
github.com/thiagolenz/erros-com-spring-boot-6-erros
Cara, esse video é ouro!
vídeo maravilhoso, obrigado
já fiz umas 2 coisas ai que vc disse pra não fazer
Spring boot é um framework espetacular, dá até gosto de trabalhar com ele.
Top , aqui em Engenheiro Schimitt e curtindo essa aula TOP 👍😎, muito bem explicado, vlw
Tem o carregamento lazzy e eager que o pessoal também não trata
Obrigado por acompanhar meus vídeos !!
Excelente conteúdo! Continue enviando videos diretos e simples assim. Parabéns!
Obrigado pela audiência Johny, em breve novos conteúdos aqui no canal!!!
parece que você fez o vídeo pra mim kkkk todos os 6 erros são dúvidas que eu tinha/tenho. Agora consigo mexer no meu projeto sabendo o que devo fazer kk valeu!! Me inscrevi aqui
Obrigado pelo feedback! realmente esses problemas acontecem bastante.
master, o teu conteúdo é ouro. Muito obrigado estão me ajudando muito.
Valeu demais!!
É são conceitos básicos, mas para quem não está se atualizando, acaba cometendo. Ótimo vídeo.
Muito obrigado!!
Cirúrgico!
Conteúdo incrível ❤
Em breve mais conteúdos , vai ter vídeo sobre Kafka!!!
obrigado professor, estou começando agora, já estava fazendo errado rs
Acontece hehehe, errar é normal, independente do nível que estamos.
Conteúdo de altissima qualidade. Muito obrigado por compartilhar.
Eu que agradeço por acompanhar o canal aqui no YT!!
Fui o inscrito 1000
Muito bom!!! Que seja o primeiro de muitos!!! Obrigado pela audência!!
Muito bom! Parabéns 👏🏻👏🏻
Então ficou uma questão aqui me martelando. Caso eu utilize a abordagem DDD, como o bean validation irá ajudar? Obrigado.
Pode colocar Beans Validation tanto nas Entity ou na API, eu prefiro colocar já na API.
Sabe muito!!
Grande Rubens, valeu !!!
Excelente conteúdo! ✌😁
Valeu pelo Feedback Ewerton :D
Ótimas dicas!
Valeu Gabriel !!!
Thiago, obrigado por este conteúdo! Tem 2 pontos que eu também considero não erros, mas práticas ruins e eu gostaria de saber sua opinião.
O primeiro é definir o controller e seus métodos como públicos. Eu sempre acho que deixando-os públicos, vc está deixando aberto demais desnecessáriamente. Como nunca vamos nos referir a eles explicitamente no código, já que serão chamados automaticamente pelo Spring, eu sinto que eles deveria ficar como package-private. O mesmo vale para métodos anotados com @Bean.
Pode ser que vc queria se referir ao controller nas suas classes de testes, mas como, normalmente, as classes de testes ficam no mesmo pacote que a classe testada, então não haveria problema com a visibilidade. Além disso, o mais comum é a gente testá-los indiretamente usando MockMvc de qualquer forma.
E o segundo ponto é retornar um ResponseEntity nos controllers. Eu sempre acho que se vc não está fazendo mudanças como alterar cabeçalhos ou cookies, é melhor retornar o DTO direto. Acredito que assim vc diminui a complexidade do código e carga mental ao ler.
O que vc acha?
Obrigado pela Audiência Wellington!! Vamos aos pontos do seu comentário:
- Particularmente eu nunca vi implementações de @Controller funcionarem com métodos private, inclusive na própria documentação do spring, todos os exemplos são com métodos public. Encontrei uma boa resposta nesse link rules.sonarsource.com/java/RSPEC-3751/
- Olhando nesse ponto de vista de arquitetura, essa questão de private/public deve se atentar mais para classes de domínio, e não nas classe de Ports (Entradas e saídas)
- O teste usando MockMvc é mais focado em teste de contrato de API, trás mais abrangência.
- A questão do ResponseEntity, eu também prefiro retornar o DTO, fica mais legível, mas é possível encontrar ResponseEntity nos projetos por aí
Forte abraço!!
@@MasterDevTV Obrigado pela resposta!
Sobre os métodos dos controllers, eu não me referia a métodos privados, mas sim a métodos "package-private".
Package-private é o jeito que eu já vi por aí para se referirem à métodos, membros de classes, que não tem nenhum dos modificadores de acesso (public, protected e private) e, por isso, são visiveis apenas dentro do pacote em que foram declarados.
Com isso, o que vc acha?
🥰😍🤩
Obrigado por prestigiar o canal!!
Entendi, mas fiquei com uma dúvida, usando caso o Bean validation não tenha uma validação para um dado é errado validar na unha? Podemos criar uma customização para validar, mas não entendi qual é o problema de validar na unha sendo que o Bean validation faz isso por baixo dos panos, poderia explicar por favor?
Fala Marcelo, beleza? o caso do Bean Validation é para utilizar em validações "simples demais" como @NotNull @NotEmpty, @Email @Positive para garantir que um valor é positivo. @Min @Max para trabalhar com intervalos válidos de valores númericos. Porém ele não atende a todos os cenários, e o excedente você pode fazer validações a mais com código sem problema. Agora validações simples automatizaveis você deve usar Beans Validations para diminuir complexidade de código sem precisar fazer uma série de IF ELSEs.
Entendi a sua linha de raciocínio. Valeu
Na classe que fica a entidade, preciso ter um construtor vazio e um com todos os dados? Ou apenas no Dto colocar o construor vazio e os dados que quero disponibilizar
Na entidade é obrigado ter um construtor vazio por causa do JPA, o construtor com todos os campos é opcional. No DTO o mesmo cenário, precisa ter um construtor vazio por causa da API rest conseguir montar o objeto.
@@MasterDevTV você é fera ! Mais um inscrito.
Agora tem record java 17
Sim, quem já usa o java 17 pode usar o record.
Chamar uma camada de service somente com a prerrogativa de salvar dados no banco me parece um tanto quanto inutil. Voce está gerando mais complexidade desnecessária, camadas de "service", "interactors", "use-cases" deveriam ser para orquestrar regras de negócio das entidades, se o seu service está só chamando o repository pra fazer o crud e retornando uma resposta, poupe a si mesmo da burocracia e chame injete o repository no controller.
excelente video, obrigado !! simples e objetivo do comeco ao fim
@validate seria como @valid ?
Bom questionamento, de acordo com a especificação @Validated é mais voltado para métodos e @valid para atributos.
Tem uma explicação detalhada aqui> www.baeldung.com/spring-valid-vs-validated
Por que utilizar `@Autowired` invés de ` final exampleRepository constructor(){this.exampleRepository = new exampleRepository() }`?
Pois quando você instancia uma classe, também precisa se preocupar com as dependências internas e assim sucessivamente. Se você coloca @Autowired você determina que o Spring tem a responsabilidade de gerenciar essas criação de objetos para o seu código.
@@MasterDevTV seria um erro anotar como @Autowired o construtor?
@Autowired
construtor(aRespository, bRespository, cRespository) {
this.aRespository = aRespository;
this.bRespository = bRespository;
this.cRespository = cRespository;
}