Aprenda de uma vez por todas o Repository Pattern e suas formas na prática com Laravel e RabbitMQ.

[@danielneto6619]

Finalmente uma abordagem lúcida sobre repositórios no Laravel.

[@sahdoio]

Interessante essa implementação de Repository. Vou brincar um pouco com ela. Muito bacana o vídeo. 👏🏻👏🏻.

[@claytons.4845]

Confesso que por um tempo utilizei o Repository apenas como proxy mas depois que comecei a estudar mais SOLID, DDD e arquitetura limpa a chave virou principalmente após entender a Inversão de Injeção de dependência a partir dai comecei a buscar a implementação de um Repository mais Genérico isso abriu portas para diversas possibilidades, gosto muito desta abordagem do RepositoryStrategy chamo carinhosamente e "plug-play". Minha sugestão é o Command Pattern sei que é um pattern relativamente simples mas recentemente vi uma implementação utilizando __invoke para chamar usecases dentro de uma estrutura Clean Arch achei sensacional estou estudando o máximo de possibilidades que esse padrão pode oferecer. Leo muito obrigado por compartilhar esse conteúdo maravilhoso isso me deixa ansioso por muito mais. kkkk Abraço até o próximo.

[@DifferDev]

Boa Clayton, obrigado pelo comentário, gosto também do conceito de UseCase como um Command patter, usando __invoke, gosto desta abordagem pois a classe do use case fica focada na ação, por outro lado temos aquela problemática de quanto maior a aplicação maior serão os use cases e acaba ficando repetitivo ficar criando os commands, mas da pra trabalhar centralização e abstração. Valeu um abraço.

[@alysonhenrique8088]

Excelente conteúdo! Nem dá pra ficar aqui escrevendo que demora a postar, porque quando posta, sempre são conteúdos profundos. Que realmente demandam tempo.

[@DifferDev]

Agradeço demais a compreensão Alyson, não é fácil, ainda mais quando quero um conteúdo bom e tentando ao máximo ser claro e didático. Obrigado pelas palavras e um abraço!

[@wellingtonnascimento3853]

ficou excelente esse conteudo ❤

[@DifferDev]

Valeu demais pelo comentário Wellington! um abraço!

[@Kacatkun]

Muito bom hehe Repository sempre é um tema que mexe com o animo da galera, principalmente de quem usa Laravel. Cara, gostei muito de como você abordou o tema fugindo do clichê de que o "Repository serve para abstrair o uso de ORMs", e que facilitaria em uma possível troca de ORM no futuro (coisa que nunca vi ninguém fazer). O uso de Repository faz muito mais sentido nesse contexto de uso fila/serviço de mensageria usando Specific Repository para desafogar operações custosas em monolitos. Show de bola. Videozão completo para começar o domingo.

[@DifferDev]

Obrigado Cássio pelo comentário, que bom que curtiu! exatamente, o conceito Repository até em sua essência não se trata só de abstrair ORMs, alias tem projetos que o pessoal até evita o uso de ORM, valeu um abraço!

[@ryanfelipe7040]

Antes de ver eu já curti. Ja sei que vai vir conteúdo top.

[@DifferDev]

Muito grato Ryan, valeu demais pela força e pelo comentário, um abraço!

[@danielevangelista2302]

Mais um video de qualidade!!!!! Ta sumido rsrsrsrsrss

[@DifferDev]

Valeu Daniel obrigado demais um abraço, vou ver se apareço mais, hehehe!

[@gssj-o8p]

Agora sim o domingo tá completo!

[@DifferDev]

Valeu Guilherme que bom que alegrou seu domingo hehehe, um abraço.

[@LuisFelipe-ul3hk]

Conteúdo de muita qualidade muito bom mesmo.

[@DifferDev]

Muito obrigado Luis Felipe, fico feliz que gostou da aula, um abraço!

[@ClaudineyPerbony]

Parabéns , TOP, TOP! Lindão o canal, só á agradecer.

[@DifferDev]

Obrigado pelo comentário, que show que gostou, um abraço!

[@rafael98php]

Conteúdo top mestre!

[@DifferDev]

Obrigado demais pelo comentário, um abraço!

[@ricardokovalskicruz9662]

Sensacional Leonardo. Muito bom este material. Parabéns.

[@DifferDev]

Valeu demais Ricardo! grande abraço!

[@BrunoMotaL]

Fala mestre! Conteúdo top🤘🏻

[@DifferDev]

Valeu bruno, agradeço demais, um abraço.

Excelente, parabéns

[@DifferDev]

Obrigado Jefferson um abraço!

[@AdrianoAraujoRosa]

Parabéns pelo ótimo conteúdo! Queria entender melhor sobre como poderíamos fazer uma implementação do Repository baseado em listagem (coleções) usando paginação e filtragem.

[@DifferDev]

Obrigado pelo comentário Adriano, é algo que penso em fazer no futuro, mas teria que ser algo com uma base já pronta de código, bom saber que achou interessante, mas é um conteúdo único, quem sabe em breve eu lance algo, valeu abraço!

[@jhonathamatias6455]

Parabéns Léo pela aula! Impossível não entender com essa explicação.

[@dersonsena-cabradev]

Que vídeo sensacional, muito bom vídeo! Nem percebi os quase 50 minutos de vídeo de tão bom que ficou, parabéns Leo.

[@DifferDev]

Opa valeu demais pelo comentário Kilderson, um abraço!

[@matheusfilho_dev]

Top demais

[@DifferDev]

Valeu Matheus um abraço!

[@mmfjunior1]

Caraca! Só agradecer mesmo, Leonardo! Muito obrigado!

[@DifferDev]

Obrigado Mario, um grande abraço!

[@marcuspmd]

Top, Parabens

[@DifferDev]

Obrigado Marcus um abraço!

[@Roinuj16]

Muito bom, Parabéns!!!

[@DifferDev]

Obrigado Edson um abraço!

[@Adahodpf]

meu nome é Eneias...o dev!

[@Ravekx]

Show

[@DifferDev]

Valeu Alex um abraço!

[@JuniorSux]

Sensacional o conteúdo e a explicação. Didática muito boa. Eu gostaria muito que houvesse a inclusão de temas como SOLID e Clean Code dentro desse assunto, pra que a gente consiga enxergar o melhor dos mundos sendo aplicado. Além disso, pra fechar com chave ouro, claro, não poderia faltar um TDD. Vale a pena um próximo vídeo com esses conteúdos? Abração!

[@DifferDev]

Obrigado pelo comentario Edson, bem possível que posteriormente eu grave vídeos sobre esses temas, lhe agradeco pela sugestão um abraço!

[@benyallan]

Eu estava esperando muito por esse vídeo

[@DifferDev]

Opa que legal, espero que tenha gostado, um abraço!

[@TheBackBlood]

Quando vai rolar aquele curso estilo Road to hero ?

[@DifferDev]

Obrigado pelo comentário Noah, opa em breve sai algo, fique de olho, vou postar por aqui, valeu pelo apoio, um abraço.

[@thiagomartins8977]

Toppp demais!!!Muito obrigado pelo conteudo!!! Atualmente tenho tentado fazer dessa forma, crio um contrato (interface) e em AppServiceProvider faco o bind desse interface com o repository em questao (produto, usuario) e crio um repository padrao so pra fazer a injecao de dependencia, e no Service faco a chamada do contrato, acha que eh uma boa dessa forma ?

[@DifferDev]

Então você precisa ver se usando somente repositório específico é bom ou não para seu projeto, se você ter que criar repositório para tudo que é acesso a dados, veja se não está criando repetições nos seus repositório e se possível troque por um repo genérico, por isso que tudo depende da necessidade, se for microsserviço daí é comum mesmo.

[@luizmagao]

Amigo assisto suas aulas, e quero aqui pedir sua ajuda em como conseguir usar tests, me adaptar em tests nos meus projetos.

[@DifferDev]

Obrigado pela mensagem Luiz, para começar a usar testes você precisa aprender sobre o PHPUnit em seguida sobre testes unitários, você precisa estudar mocks e TDD e começar sempre seus projetos com testes, assim se habitua a usar testes.

[@patrickbarboza7575]

Se eu quisesse usar o product_id para por exemplo criar uma relação, como eu faria? Retornaria um domínio no método save ao invés de bool?

[@DifferDev]

Obrigado pelo comentário Patrick, não, o método save tem o objetivo somente de persistir dados, o que você pode é ter uma implementação de DataMapping dentro do seu repository para que faça o mapeamento do seu domínio e resolva uma relação, assim no objeto passado como referencia você injeta a relação com um domínio e após o flush, o objeto passado como armazenamento pode estar com seu pai, porém isso só sera viável em um comportamento para banco de dados, no caso de fila é preciso o mecanismo de busca separadamenta para retornar um elemento da relação, e como precisa-se de flexibilidade o relacionamento não deve ser automatizado, a não ser que se use um mecanismo de mapeamento especialista em determinada infra.

[@nicolasromero6144]

Massa o conteúdo, obrigado por compartilhar, vc poderia fazer um caso de uso de rabbitmq ou Kafka? Tipo seu uso na vida real ? Ou depois de estar na fila quais são os usos de usar essas tecnologias??

[@DifferDev]

Obrigado pelo comentário Nicolás! Boa sugestão é algo que está nos planos de lançar um conteúdo, quem sabe algo com Kafka que tem pouco por aí com PHP

[@JoaoPedro-uw8nz]

O seu conteúdo sobre php é um dos mais completos e avançados que já encontrei, pagaria tranquilamente por um curso com a qualidade dos seus videos.@@DifferDev

[@DifferDev]

@@JoaoPedro-uw8nz muito obrigado pelas palavras João em breve vou lançar um curso, se quiser se inscrever aqui te comunico assim que saír.

[@hisok4dev192]

Poderia me falar o nome da extensão rest e da extensão de fazer consultas no banco que usou no vídeo? Ambas do vscode

[@DifferDev]

Opa obrigado pelo comentário, um é o "REST Client" do Huachao Mao, e o outro é o "Mysql" do Jun Han

[@alysonhenrique8088]

Fala. Léo! Eu implementei essa solução em um dos meus projetos de estudo. Mas tenho uma dúvida quando a singularidade dos repository. Na empresa onde trabalho, esse padrão foi implementado do jeito errado que você falou, cada model tem seu repository, e usamos eles para além do crud, fazer também consultas específicas para um model. Esse tipo de implementação está equivocada? Digo: uma consulta mais específica deveria ser um método privado do próprio model, que poderíamos acessar através desse padrão que você ensinou? Exemplo: Uma consulta que retorna um array associativo onde a chave é o nome do cliente, e o valor sua data de aniversário. Onde trabalho, implementamos isso dentro do repository referente ao model, com o método: findCustomerBirthdayToForm(). Mas faria mais sentido que esse método pertencesse ao próprio model? Sou iniciante, apenas um ano de xp, mas me veio essa dúvida. Espero não estar incomodando! hehehe Se eu não tiver sido claro, comentem aqui! Valeu, povo!

[@DifferDev]

Opa Alyson, obrigado pelo comentário, excelente dúvida, na verdade não está errado este modelo da sua empresa, o ponto a se perguntar é se o repository será papel de ator da mudança de armazenamento, ou seja, fazer uma troca de implementação de um DB para uma fila por exemplo. Então o que eu disse foi, se não houver esse objetivo, você pode trabalhar com Repository para cada model sim, e é até mais interessante, pois você não coloca a responsabilidade de query builder nos Models do Laravel, colando lá ocasionará muita dependência ao ORM do Laravel, a ideia dos Repositories é não implementar regras de persistencia/busca nos Models diretamente, mas sim na camada de infraestrutura(repository), assim você ganha mais mobilidade. Por ultimo se você precisar de recursos mais sofisticados como filtros, paginação, ordenação e limitação, dai aconselho trabalhar um modelo de Specification Pattern e Repository Genérico e implementado-o nos repositórios específicos, exatamente para abstrair esses recursos e conseguir adaptar(Adapter) para outras tecnologias como filas, search engine ou queues sem muito esforço. Como falei no vídeo, errado é ter repositorios vazios(anêmicos) que só recebem Models e não fazem nada demais a não ser chamar os métodos dos models, isso sim é uma implementação sem benefício, daí melhor usar as Models diretamente(o que evito ao máximo para aplicações robustas).

[@alysonhenrique8088]

@@DifferDev Show de bola, Léo! Sempre esmiuçando tudo! Valeu Pelas dicas!