Video top. Ja eu prefiro injetar uma Request no metodo do controller e lidar com os dados/parametros da requisicao la, usando validation e o que for necessario para validar, penso que o service deve processar e cuidar da parte complexa mas ela ja tem que receber os dados certos. Entao ficaria algo como function editUser(UserRequest $request) { $this->service()->editUser($request->all())} (so exemplo), por que as vezes validacoes dao mais codigo do que processar algum dado, entao termina "poluindo" muito o service.
sou novo em laravel e programação em geral, eu estou desenvolvendo um aplicativo para organizar eventos da comunidade de um game que eu gosto muito, Apex Legends, e o sistema de pontuação(calculo que atribui um certo ponto a uma determinada posição na partida jogada) e match points tava todo na controller, com algumas funcoes chegando a ter mais de 100 linhas, depois desse video eu vou refatorar toda minha controller, limpar e jogar toda essa regra de negocios nas services, OBRIGADO mais uma vez Urnau, EXELENTE video, te desejo MUITO sucesso, abraços!!!!!!
Booooa Kayazika... Fico feliz em ter ajudado nessa... Além de diminuir a responsabilidade da Controller, você conseguirá aplicar testes unitários com tranquilidade nas services que criar. Sucesso em sua jornada!
Parabéns pela divulgação desses conceps Urnau, demorei uns anos para implementar conceito de de SOLID. Só colocaria uma Classe factory no artefatos de services , para no metodo(Services) nao ficar dando new. e tbem utilizaria uma interface. Mas parabens novamente pela divulgacao.
Boa pergunta Douglas... Há quem use as services como Repostory, mas o fato é que as Services tem a principal características armazenar as regras de negócio da aplicação, ou seja, tudo quanto é lógica de processamento. Já as repository elas são para realizar consultas externa ao PHP, por exemplo consultas ao Banco ou a APIs. Um exemplo prático, tu tem uma query gigante com Joins e Wheres, então tu pode criar um método em uma repostirory para tornar reutilizavel esta query em várias partes do sistema, assim se um dia tu precisa mudar algo na query então só precisaria atualizar na repository. Se quiser saber mais sobre repository tenho este vídeo: ruclips.net/video/-TBINR4sBuE/видео.html . Espero ter ajudado, suecsso!
@@devtechtips saquei, a ideia do services é criar algumas lógicas que não envolva consulta no banco necessariamente, enquanto repository seria mais para acoes no db, top seus vídeos parabéns 👏🏻👏🏻
@@douglasduarte00 Boooa... Se você não tem repository ai faz sentido sim fazer querys dentro da service. Mas a partir do momento que você implementar repository ai faz sempre mais sentido na service você chamar métodos da repository para obter dados do Banco ou API.
Muito boa explicação amigo! Uma dúvida: Em minha Controller de Produtos por exemplo, tenho todos os métodos Crud disponíveis (index, show, store, update, delete). Uma forma bacana de organizar isso seria cada um desses métodos não interagir diretamente com a model, utilizando o eloquent, e sim abstrair isso para uma classe que faça essa relação com a model, certo? Desta forma minha Controller chamaria os métodos do repository, que por sua vez se comunicaria com a model. Seria mais ou menos por ai? Pelo que entendi, Services seria uma camada a mais para eu não encher minha controller de métodos privados ou coisas do tipo, com regras de negócios ou método gigantes. A dúvida é: Se em um desses métodos do service eu precisar interagir com a model, eu deveria utilizar um repository dentro dele, e não chamar a model diretamente, correto? Você acha interessante eu ter por exemplo um ProductService, que possua todos os métodos que eu chamaria no meu crud, por exemplo: getAll(), findOne(), update(), delete(), findByName(), e assim a controller chamaria o service, que por sua vez conversaria com a repository? É que as vezes acho meio redundante criar todos os métodos crud dentro de um service, como mostram alguns cursos por ai. Para min creio que faça mais sentido utilizar services como em seu exemplo: Métodos específicos contendo regras de negócio, e não necessariamente todos os métodos utilizados em meu crud. Assim metódos como store, show, updade só interagiriam com a repository na controller. É mais ou menos por ai? Valeeu!!
Ótima questão Artur.... Vocês está sim correto no seu raciocínio, e na pratica o que vc pode levar em consideração é: a controller só vai fazer uma query e devolver? se sim, então chama direto a repository, se não, então chama a service e ela se resolve. Outra coisa, se a regra de negócio é muito pequena e vc precisa ser agil na entrega, então você também pode acabar dando mais responsabilidade a controller, e num momento de fatoração então ajustar as coisas pros seus devidos lugares. Mas parabéns, seu nível de compreensão está excelente... Sucesso!
Qual a diferença de uma Services para o Model em si? Sou iniciante e não entendi muito bem, parece que apenas usando o Model, eu já teria esses benefícios como modularidade e tal...
O básico sempre será o clássico MVC. Mas além dele, você é livre para criar outros módulos que encapsulam mais ainda a aplicação aumentando a manutenibilidade.
Video top. Ja eu prefiro injetar uma Request no metodo do controller e lidar com os dados/parametros da requisicao la, usando validation e o que for necessario para validar, penso que o service deve processar e cuidar da parte complexa mas ela ja tem que receber os dados certos. Entao ficaria algo como function editUser(UserRequest $request) { $this->service()->editUser($request->all())} (so exemplo), por que as vezes validacoes dao mais codigo do que processar algum dado, entao termina "poluindo" muito o service.
sou novo em laravel e programação em geral, eu estou desenvolvendo um aplicativo para organizar eventos da comunidade de um game que eu gosto muito, Apex Legends, e o sistema de pontuação(calculo que atribui um certo ponto a uma determinada posição na partida jogada) e match points tava todo na controller, com algumas funcoes chegando a ter mais de 100 linhas, depois desse video eu vou refatorar toda minha controller, limpar e jogar toda essa regra de negocios nas services, OBRIGADO mais uma vez Urnau, EXELENTE video, te desejo MUITO sucesso, abraços!!!!!!
Booooa Kayazika... Fico feliz em ter ajudado nessa... Além de diminuir a responsabilidade da Controller, você conseguirá aplicar testes unitários com tranquilidade nas services que criar. Sucesso em sua jornada!
Excelente explicação, Urnal. A comunidade só agradecer por pessoas como você. Obrigado
Excelente vídeo, mas sevAIces me mata 😂. Excelente vídeo parabéns e obrigado.
Concordo, kkkkkkkkkk
Servaices é tenso mesmo kkkkkkkk
Parabéns Urnau pela explicação e apresentação do conteúdo, com uma introdução, tópico abordado, roteiros, capítulos, etc... Já fiz minha inscrição!
Vlw Luiz... Fico feliz que tenha gostado... Sucesso!
Acompanhando o conteúdo !
Booooa PW... Vamos que vamos... sucesso!
Ótimo seu canal, nao vi videos recentes, torcendo pra nao ter parado
Você é top! Aprendo mais assim vendo projeto na pratica
Parabéns pela divulgação desses conceps Urnau, demorei uns anos para implementar conceito de de SOLID. Só colocaria uma Classe factory no artefatos de services , para no metodo(Services) nao ficar dando new. e tbem utilizaria uma interface. Mas parabens novamente pela divulgacao.
Conteúdo top, Obrigado Urnau!
Vlw Celso... sucesso!
Top de mais 👏🏻👏🏻👏🏻👏🏻
Vlw Webkobalski... Sucesso!
Esse tipo de conteúdo é muito bom ! recomenda algum livro para aprofundar mais ?
Muito bom, obrigado.
Valeu Gutembergue... Sucesso!
Muito top!!
Vlw Tarcisão... Sucesso!
Qual a diferença entre services e repository?
Boa pergunta Douglas... Há quem use as services como Repostory, mas o fato é que as Services tem a principal características armazenar as regras de negócio da aplicação, ou seja, tudo quanto é lógica de processamento. Já as repository elas são para realizar consultas externa ao PHP, por exemplo consultas ao Banco ou a APIs. Um exemplo prático, tu tem uma query gigante com Joins e Wheres, então tu pode criar um método em uma repostirory para tornar reutilizavel esta query em várias partes do sistema, assim se um dia tu precisa mudar algo na query então só precisaria atualizar na repository. Se quiser saber mais sobre repository tenho este vídeo: ruclips.net/video/-TBINR4sBuE/видео.html . Espero ter ajudado, suecsso!
@@devtechtips saquei, a ideia do services é criar algumas lógicas que não envolva consulta no banco necessariamente, enquanto repository seria mais para acoes no db, top seus vídeos parabéns 👏🏻👏🏻
@@douglasduarte00 Boooa... Se você não tem repository ai faz sentido sim fazer querys dentro da service. Mas a partir do momento que você implementar repository ai faz sempre mais sentido na service você chamar métodos da repository para obter dados do Banco ou API.
Muito boa explicação amigo! Uma dúvida:
Em minha Controller de Produtos por exemplo, tenho todos os métodos Crud disponíveis (index, show, store, update, delete). Uma forma bacana de organizar isso seria cada um desses métodos não interagir diretamente com a model, utilizando o eloquent, e sim abstrair isso para uma classe que faça essa relação com a model, certo? Desta forma minha Controller chamaria os métodos do repository, que por sua vez se comunicaria com a model. Seria mais ou menos por ai? Pelo que entendi, Services seria uma camada a mais para eu não encher minha controller de métodos privados ou coisas do tipo, com regras de negócios ou método gigantes. A dúvida é: Se em um desses métodos do service eu precisar interagir com a model, eu deveria utilizar um repository dentro dele, e não chamar a model diretamente, correto? Você acha interessante eu ter por exemplo um ProductService, que possua todos os métodos que eu chamaria no meu crud, por exemplo: getAll(), findOne(), update(), delete(), findByName(), e assim a controller chamaria o service, que por sua vez conversaria com a repository? É que as vezes acho meio redundante criar todos os métodos crud dentro de um service, como mostram alguns cursos por ai. Para min creio que faça mais sentido utilizar services como em seu exemplo: Métodos específicos contendo regras de negócio, e não necessariamente todos os métodos utilizados em meu crud. Assim metódos como store, show, updade só interagiriam com a repository na controller. É mais ou menos por ai? Valeeu!!
Ótima questão Artur.... Vocês está sim correto no seu raciocínio, e na pratica o que vc pode levar em consideração é: a controller só vai fazer uma query e devolver? se sim, então chama direto a repository, se não, então chama a service e ela se resolve. Outra coisa, se a regra de negócio é muito pequena e vc precisa ser agil na entrega, então você também pode acabar dando mais responsabilidade a controller, e num momento de fatoração então ajustar as coisas pros seus devidos lugares. Mas parabéns, seu nível de compreensão está excelente... Sucesso!
@@devtechtips muito obrigado pela aula meu querido! Desejo todo sucesso pra vc :) Um abraço!
Qual a diferença de uma Services para o Model em si? Sou iniciante e não entendi muito bem, parece que apenas usando o Model, eu já teria esses benefícios como modularidade e tal...
O básico sempre será o clássico MVC. Mas além dele, você é livre para criar outros módulos que encapsulam mais ainda a aplicação aumentando a manutenibilidade.
só me deu agonia de voce chamar Services de serviiices. Em ingles é Seervices. Serviços.
so 100 linhas kkkkk, já peguei um controler com mais 2700 linhas de funções