Faz todo sentido, já perdi um tempo com isso tbm, mas talvez esse pattern não seja para quem usa frameworks modernos como o Laravel. Trabalho com um sistema legado que usa Propel como orm e nenhum framework. Acho que aí cairia bem o primeiro desenvolvedor ter me feito o favor de usar repositories, pq hoje eu estaria trocando tudo pelo eloquent.
É, o repository seria pra implementar lógica relacionada a entidade de uma tabela, com uma salvaguarda de poder mudar o orm depois. Mas essa lógica pode muito bem ser colocada no model desse orm se você tem convicção de que nunca vai mudar o orm...
Fala galera, primeiro parabéns pelo trabalho que vcs fazem, curto bastante, mas nesse ponto eu quero descordar do Danilo, o padrão existe pq a necessidade existe, o pessoal utiliza-se do único argumento de troca de tecnologia DB pq não conhece os reais benefícios do padrão. Nesse caso em específico, alguns sistemas nunca vão precisar mesmo, mas o repository pattern traz vários ganhos, como por exemplo, separação de responsabilidades, facilita a manutenção e possibilita uma abordagem uniforme do acesso aos dados, simplicidade no acesso aos dados quando a lógica de consulta é mais complexa, além disso, devo salientar que apesar da troca de DBMS não ser tão comum na maioria dos sistemas, a utilização de múltiplos DBMSs é fato comum em muitos casos. Deixo meu comentário de forma construtiva, pois iniciantes acabam não tendo filtros suficientes para entender esse tipo de opinião que o Danilo expressou.
Boa Rafael! Com certeza os padrões existem realmente para matar um problema especifico, nosso foco é justamente trazer uma luz para a galera que implementa um pattern por ele estar na "moda" ou por que acredita que isso pode ajudar em algum caso que ele ainda não sabe se vai acontecer. Nosso foco é ensinar a manter a produtividade e escrever bons códigos sem trazer complexidade desnecessárias.
Faz todo sentido, já perdi um tempo com isso tbm, mas talvez esse pattern não seja para quem usa frameworks modernos como o Laravel. Trabalho com um sistema legado que usa Propel como orm e nenhum framework. Acho que aí cairia bem o primeiro desenvolvedor ter me feito o favor de usar repositories, pq hoje eu estaria trocando tudo pelo eloquent.
Quando não se implementa um repository, a lógica vai para onde? Para o Model?
É, o repository seria pra implementar lógica relacionada a entidade de uma tabela, com uma salvaguarda de poder mudar o orm depois. Mas essa lógica pode muito bem ser colocada no model desse orm se você tem convicção de que nunca vai mudar o orm...
o eloquent ja faz tudo que uma repository faz ,e ele ja vem no laravel ou seja nao faz sentido implementar
Fala galera, primeiro parabéns pelo trabalho que vcs fazem, curto bastante, mas nesse ponto eu quero descordar do Danilo, o padrão existe pq a necessidade existe, o pessoal utiliza-se do único argumento de troca de tecnologia DB pq não conhece os reais benefícios do padrão. Nesse caso em específico, alguns sistemas nunca vão precisar mesmo, mas o repository pattern traz vários ganhos, como por exemplo, separação de responsabilidades, facilita a manutenção e possibilita uma abordagem uniforme do acesso aos dados, simplicidade no acesso aos dados quando a lógica de consulta é mais complexa, além disso, devo salientar que apesar da troca de DBMS não ser tão comum na maioria dos sistemas, a utilização de múltiplos DBMSs é fato comum em muitos casos.
Deixo meu comentário de forma construtiva, pois iniciantes acabam não tendo filtros suficientes para entender esse tipo de opinião que o Danilo expressou.
Boa Rafael! Com certeza os padrões existem realmente para matar um problema especifico, nosso foco é justamente trazer uma luz para a galera que implementa um pattern por ele estar na "moda" ou por que acredita que isso pode ajudar em algum caso que ele ainda não sabe se vai acontecer. Nosso foco é ensinar a manter a produtividade e escrever bons códigos sem trazer complexidade desnecessárias.