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
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?
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.
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.
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.
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
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.
Para acessar o código desse exemplo acesse o link abaixo:
github.com/thiagolenz/erros-com-spring-boot-6-erros
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 !!
Cirúrgico!
master, o teu conteúdo é ouro. Muito obrigado estão me ajudando muito.
Valeu demais!!
Spring boot é um framework espetacular, dá até gosto de trabalhar com ele.
É são conceitos básicos, mas para quem não está se atualizando, acaba cometendo. Ótimo vídeo.
Muito obrigado!!
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.
vídeo maravilhoso, obrigado
já fiz umas 2 coisas ai que vc disse pra não fazer
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!!!
Conteúdo incrível ❤
Em breve mais conteúdos , vai ter vídeo sobre Kafka!!!
Cara, esse video é ouro!
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!!
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?
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 !!!
Ótimas dicas!
Valeu Gabriel !!!
Excelente conteúdo! ✌😁
Valeu pelo Feedback Ewerton :D
Fui o inscrito 1000
Muito bom!!! Que seja o primeiro de muitos!!! Obrigado pela audência!!
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.
🥰😍🤩
Obrigado por prestigiar o canal!!
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.
Bom, isso foi apenas um exemplo, o cara não precisa cria algo super complexo no service apenas para explicar algo.
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;
}