Por que eu não gosto de Laravel - Conhecendo padrões de ORM | Dias de Dev 

Parece que há uma confusão entre o que o framework te oferece e aquilo que você deseja para o seu domínio. Laravel apenas te oferece um modelo de persistência. Você continua livre para implementar teu modelo de domínio como quiser (ex. objetos PHP simples). O core da tua solução será independente de toda a infraestrutura fornecida pelo Laravel. Se o framework utiliza active record ou data mappers tanto faz em relação ao seu domínio. Nesse sentido não tem como afirmar que o Laravel é ruim só por ter escolhido active record como forma de implementar o modelo de persistência.

Trabalho com Laravel desde a versão 3. Me ajudou muito tanto profissionalmente/financeiramente, quanto em ser um desenvolvedor melhor. Apesar da blasfemia do senhor, mais um conteúdo top e bem argumentado! Hahaha - De fato, esse é um ponto que eu também critico, e acho que a maturidade e senioridade residem, mais uma vez, nos fundamentos, depois na ferramenta. O Laravel ( e nenhum outro framework ) te limita se você souber os fundamentos - nada impede de usar o repository pattern ou um data mapper. Inclusive, você pode usar o Doctrine com Laravel - fica a dica para os novatos que já chegaram aqui para defender ferramenta, isso muda pessoal, vai e vem, se atentem aos princípios e conceitos...Continue com o canal e conteúdo, manda muito bem!

👀

Apesar de não curtir tb Active Record, temos que entender que o "Model" do Active Record não é a sua entidade, e sim uma classe para falar com o Banco, diferente de seu domínio onde tem suas regras de negócio (agregados, entidades, vos, etc) . O maior problema é quando você coloca regras de negócio no model (que não deve ter essa responsabildiade). Model Entidade. Model => Banco. Entidade => Domínio. Se fizer esse ajuste, tudo muda completamente. Valeu pelo vídeo. Ganhou mais um inscrito ;)

Muito bom Vinicius! Programo com o Symfony a anos e concordo com os pontos apresentados. Uma coisa que também me incomoda no Laravel são os métodos mágicos. Parabéns pelo excelente vídeo!

Bem argumentado, mas alguns pontos: - O trabalho para substituir o Doctrine numa aplicação Symphony, é o mesmo para substituir o Eloquent numa aplicação Laravel - O Eloquent, apesar de ser desenvolvido pela mesma equipe do Laravel, não é acomplado ao Laravel. Ele é uma biblioteca separada e independente. - Por ser uma biblioteca independente, vc pode usar o Eloquent em aplicações não-Laravel. - Exemplo: diversos plugins WordPress que mantenho. Quem instala meus plugins, instala como se fosse outro plugin qualquer. E é muito fácil mapear os Models com as tabelas do WordPress. - O Eloquent não é acoplado ao banco de dados. Você pode usar em qualquer base de dados existente. - Exemplo 1: Leio e escrevo em tabelas core do WordPress com o Eloquent - Exemplo2 : Uso o Eloquent para mapear fontes de dados que não são banco de dados relacionais. Um exemplo é um data warehouse que me fornece uma API para ler dados. Isso me fornece uma abstração e maior facilidade em organizar o código. - Você também pode usar outros ORM no Laravel, como por exemplo, o próprio Doctrine. E isso é feito facilmente, já que o Laravel não depende do Eloquent - Se o Laravel parar de desenvolver o Eloquent, você pode facilmente substituir por classes próprias (eu já fiz isso antes) usando o Doctrine por baixo dos panos, por exemplo - Sobre o acomplamento de domínio, aí é uma questão mais de como você estrutura seu código. Eu por exemplo mantenho o código front-end em um projeto separado, uso uma organização em DDD (domain-driven design), minhas regras de negócio estão em Actions e não no Model, uso DTOs para o fluxo de dados ao invés de tê-los no Model, etc. No fim das contas acredito ser só uma questão de gosto pessoal mesmo. Mas é importante seguir um framework, mesmo não gostando de alguns detalhes. É mais sobre ter uma linguagem comum com outros desenvolvedores do que o que é melhor do ponto de vista técnico.

Conteúdo sempre muito bom, você tem sido uma grande referência pra mim, obrigado!

Embora eu esteja estudando laravel, achei muito boa a sua explicação! Sempre me faz ver coisas a mais que eu não conhecia. Eu gostaria de ver a sua opinião sobre mais coisas que você não gosta no laravel. Acredito que me seria muito útil para entender melhor mais coisas e abrir possibilidades maiores de aprendizado! Valeu Vinícius

Adorei o vídeo! Confesso que sou apaixonada pelo Laravel, mas venho tentando desapegar um pouquinho e aprendendo a não ficar tão dependente do framework. Gosto muito da sua didática, Vinícius. Grande referência para mim com o PHP!

Entendi. Você não gosta de frameworks e bibliotecas que usam o padrão active record. Mas e se eu desenvolver um componente que usa esse padrão de forma nativa na minha aplicação? As minhas próprias classes seguindo o padrão active recorde e os modelos estendendo essas classes. O que você diria?

Vídeo bem bacana, mas são argumentos que vc podia usar em 2018/2019. O Framework evolui muito pra desacoplar muitas dependências. Vale a pena dar uma revisada to gostando bastante.

Parabéns pelo vídeo Vinícius, enriquecedor como sempre! Quando puder fale um pouco mais sobre o framework Laminas se possível. Agradecido, sucesso.

Tem gente chorando hoje com as mudanças do laravel, acho que eles derem um tiro no pé com essa versão 11

MVC é vida!

Também tenho meus receios com os acoplamentos do Laravel, e também essas mágicas que são complicadas pra resolver bugs quando aparecem. Tenho usado ele pra projetos simples. Ótimo vídeo!

Eu uso o Laravel a 5 anos e adoro o framework por todas as facilidadades e a documentação é bem facil de encontrar. Porem nos ultimos anos como tenho feito projetos grandes e que demandam muita manutenção e que a reutilização é necessária. Percebi que o actived record não é uma abordagem para projetos grandes e que irão durar muito tempo. Pois se voce não saber criar bem sua arquitetura com um clean architecture ou ddd, voce vai ser embolar e vai chegar um ponto que a manutenção será extremamente complicada. Um problema do active record que eu acho que vem a falhar do paradigma de ornetação a objetos: ENCAPSULAMENTO.

Bom, a parte do AR eu entendo e acho que é questão de opinião mesmo - o que eu não concordo é com a parte de que AR é problemático para aplicações que precisam durar muito tempo: praticamente todos os apps gigantes escritos em Rails usam AR. A parte de sair do Laravel também me parece irreal - mesmo que o Laravel acabasse por algum motivo, existiriam forks, ou você poderia simplesmente importar o código do framework para o seu projeto. Consigo entender o “problema” do acoplamento, mas isso é genérico e aconteceria também se você tivesse uma classe que usasse o Request do Symfony, por exemplo. Pelo que eu entendi o motivo de você não gostar do Laravel na verdade é o Eloquent… como você se sentiria num projeto Laravel com Doctrine, por exemplo? Abs

o que eu gosto mesmo é do CakePHP, acho o Laravel MUITO modinha e é bem complicado ao contrário do CakePHP que na minha opinião deveria ser o queridinho igual o Python é hoje em dia por exemplo.

Muito bom cara! Gosto de ouvir outros desenvolvedores. Isso me ajuda a ter mais ideias na hora de resolver as buchas.

Eu utilizo a anos o Adianti Framework, o mesmo me proporcionou uma qualidade de vida enorme

Na empresa que trabalho nós torcemos o nariz pelas mesmas coisas. Começamos um projeto tentando usar DDD com o Eloquent e foi um desastre. Além disso, nós já trabalhávamos separando a camada de BD em repositories e não fazia o menor sentido, pois o Model já fazia os 2 papéis. Ao fim, utilizamos o pacote laravel-doctrine e nos deu o melhor dos dois mundos: todo arcabouço de coisas que o laravel oferece com toda vantagem de usar o doctrine. Muito bom vídeo. Muito legal saber que outras pessoas tem dores parecidas.

Top demais o conteúdo, ontem mesmo eu estava conversando com o ilustre Marcel dos Santos, sobre Laravel e as diferenças, o que chegou justamente na abordagem de Data Mapper e Active Records, hoje impressionantemente sou agraciado com esse vídeo! Conteúdo top, a semana está ótima a nível de conhecimentos. Obrigado Vinícius.

Na solução que você sugeriu, o Doctrine cai no mesmo problema do ORM pŕoprio do Laravel...se o Doctrine não for mais mantido? O Laravel tem provedores de serviço que matam o mesmo problema, eu posso mudar o driver de persistência no metodo boot(). A injeção de dependência que você sujeriu o Laravel faz de forma automática com typehints do PHP sem precisar instanciar nada.

Gostaria muito que vc falasse sobre ORM. Em especial sobre o doctrine que é um ORM de mercado e como ele faz o mapeamento objeto relacional. Até desse um exemplo de persistência de dados.

Começando no PHP, muito bom o conteúdo!

Utilizo o data mapper desde 2007. Muito bom o teu vídeo!

O q falta ao PHP é uma camada de abstração de banco de dados nativa da própria linguagem. O Java tem o JPA que os ORMS implementam. Em teoria, se voce muda o ORM/implementação do JPA, você não sente porque a linguagem te oferece as annotations e as interfaces e o ORM a implementação.

Vinicius, parabéns pelo conteúdo. Sou fã do seu trabalho tanto aqui no you tube, quanto na Alura. Eu tenho uma grande dificuldade com relação a entender como montar a infraestrutura de um projeto (Camada de negócio, camada de aplicação, etc). Se você pudesse criar um vídeo mostrando como estruturar um projeto, isso ajudaria muito! Forte Abraço. 🤜

Eu não sou do tipo que curte comparar ferramentas, afinal, da linguagem ao framework, tudo é ferramenta, todas tem seus pontos forte, fracos e propostas para resolver problemas, quem escolhe qual ferramenta usar é o profissional, no fim das contas é a necessidade do produto que deve ser levada em consideração, se laravel atender, tá bom, se não atende, tá bom também. Acho que evoluções ocorrem por conta de situações como essa dita no vídeo, que são aplicadas e posteriormente percebidas que podem ser melhor, a exemplo de como javascript mudou positivamente. Lembro da transição no react quando entrou os hooks, foi uma mudança bem drástica, literalmente precisava rescrever o código sem poder atualizar a versão, foi doloroso mais os benefícios justificaram a decisão, isso só exemplifica que conforme as coisas vão evoluindo a forma de fazer muda, poderá quem sabe no futuro a evolução desse fato, que convenhamos, nem é de fato um impedimento para uso do laravel, dar para optar por não usar o ORM, logicamente isso exige um dor de cabeça que realmente se deve questionar se o produto precisa mesmo disso e se é o caso escolher o laravel. O vídeo foi bem legal, parabéns. Eu não duvido que vai ter gente que vai ver isso de forma muito extremista sem se quer saber sobre o de fato esta sendo dito, mas é normal isso, essas pessoas vão ganhar maturidade e um dia entender que esses questionamentos são válidos e é isso que faz as coisas ir melhorando, afinal, nosso papel é resolver problemas sempre pensando na melhor forma de se fazer.

Realmente, o Eloquent tem essas limitação, sendo mais usado para aplicações mais simples, ou seja, em que a questão do acoplamento pode ser negligenciada até certo ponto. Para aplicações mais complexas e com um tempo de vida maior, o Laravel suporta o Doctrine.

Olá como vai. Você pode usar o Laravel com Doctrine. Aqui na empresa, como trabalhamos com o banco de dados Oracle, o Doctrine foi a melhor escolha, porque na época o Eloquente não era recomendado para este SGBD.

o melhor do laravel eh o Serivce Container e eh o que me faz continuar usando ele (Isso eh claro dependendo do problema)! Isso tudo que vc falou eh resolvido apenas com o Repository pattern! Os problemas nao sao as ferramentas e sim quem usa! Nao adianta ter um revolver na mao e vc usar ele dando coronhada! O Laravel eh simplesmente um dos melhores frameworks de todos os tempos... vamos escrever menos codigo, e manter o mais simples possivel, com bastante teste automatizado, eh isso que eh o mais importante no mundo da programacao!

Vinicus lança um video sobre o laravel Doctrine, se possivel um curso na Alura kk

É melhor fazer tudo em Assembly, assim o código fica bem independente

Boa Vinícius ! Conteúdo muito bom, sempre te acompanhando ! Cara, um conteúdo que queria muito ver tu fazendo é ferramentas que tu utiliza para ter um padrão de código, por exemplo sei que tu utiliza o phpStorm, mas o que tu utiliza nele para manter o padrão de código padronizado ? O workflow, codesniffer ... entre outros.

Muito boa a sua visão sobre o tema, conteúdo de qualidade!

Eu até entendo seu receio de depender de um código que você não mantém, mas se formos pensar assim, ninguem faz nada com as coisas dos outros...todo mundo tá sujeito a ser abandonado num aspecto, seja um plugin, seja uma lib, seja um framework ou até mesmo um sistema!

O vídeo ficou bem legal, mas acho que você podia ter explorado mais coisas além desse acoplamento do active records, fica a dica pra mais alguns vídeos explorando os problemas de frameworks

Lendo o título buguei total, aprendi a usar Laravel no teu curso da Alura kk, mas entendi o ponto.

A questão que eu não entendi é: se o Eloquent é o "único problema" do Laravel, ele pode ser ignorado e se usar o Doctrine no lugar. No nosso projeto a gente fez o oposto, puxamos o Eloquent pra acoplar num ORM arcaico (nível mysql-ext), e ele não traz nem o sistema de migrations nem eventos junto. Ele é bem desacoplado (tanto que é uma das duas partes do framework com nome próprio) e, no meu parco entendimento, seria perfeitamente possível usar toda a extensão do Laravel com Doctrine ao invés do Eloquent. E o argumento de abandono é parcialmente falho: vc compara o abandono do framework (que certamente teria uma sobrevida caso o louco do Taylor dê uma de.... louco, assim como aconteceu com o Faker) com o abandono de uma library. Ter código acoplado a uma library é realmente delicado, mas é muito importante pesar o quanto de overhead o desacoplamento pode causar - com código mais verboso e mais complicado de se entender, por exemplo. Se a library tem uma expectativa de vida longa (como é o caso desse assunto), pode valer a pena sim o acoplamento, visto que o efeito colateral ruim é, principalmente, uma pequena hipótese de um futuro distante. Usando o mesmo raciocínio, seria ruim então que os templates sejam baseados em Twig ou Blade, ou que todo seu fluxo de request/response seja dominado pelo formato de MVC do framework que você escolher. Afinal, se o framework for abandonado, vc vai precisar adaptar mil métodos e afins para outro framework. Acredito que a discussão seria mais produtiva se expandisse no argumento de AR vs DM. Envolver frameworks inteiros e discutir abandono de libraries nesse assunto só ajuda a dispersar o tópico e criar polêmica rs

Os meus motivos são: ele complica e da opinião em coisas que deveriam ser simples, ele é em PHP, o pessoal adiciona um monte de coisa acoplada como "octane" para solucionar problemas que ou é do laravel ou da linguagem que ele foi escrito, vc transfere a carga disso tudo para techs de infra sem a necessidade dificultando o deploy e a manutenção, e é problemático para atualizar pois na maioria das vezes vc tbm que criar outro projeto do zero para atualizar de uma versão para outra. Por isso vale mais a pega passar para node, com o NextJS por exemplo, vc tem bem menos atrito e e faz tudo isso funcionar melhor

Entendi seu ponto e o bom é que na realidade você não falou mal do Laravel, como se ele fosse um framework horrível, e sim apenas não gosta de alguma parte de como ele trata alguma funcionalidade específica. E o melhor é: cada um consegue continuar gostando dos usuários do jeito que prefere.

Eu estudo laravel desde 2019, nunca usei ele mais sempre to estudando quando posso

Opinião interessante, mas que não se aplica ao mercado. Como opinião interessante não paga meus boletos...

O Eloquent também pode ser usado externamente (fora de um projeto Laravel). E também não acho um bom motivo para não gostar de Laravel, pois você pode usar o Repository Pattern para resolver esse problema. Acho que qualquer linguagem/framework pode ser bom, desde que usado da maneira correta. O que eu não gosto muito é a forma como o Eloquent monta as queries, poderia ser mais otimizado.

Bom vídeo, concordo em alguns pontos, mas uma pergunta, se tu pudesse escolher livremente a tecnologia para um projeto novo, tu faria o uso de PDO com Repository Pattern ou usaria algo semelhante ao Doctrine?

Eu gostaria muito da sua opinião sobre o framework yii2. 😊

Eu gostaria de ver um vídeo seu sobre Laminas/Mezzio.

Onde eu trabalho o pessoal normalmente cria um repository pra trabalha com o crud, uma convensão pq se vc for usa o model no service pra fazer as operações de banco fica bem verboso o codigo

Boa vini! E sim, isso me incomoda também. Me sinto muito preso quanto a isso (apesar de utilizar o Laravel no dia a dia). Uma pergunta, não sei se você pode responder, mas se puder, seria ótimo pois fiquei muito curioso. Qual framework PHP voce utiliza no seu dia-a-dia? Forte abraço e parabens pelo conteúdo!

Como essa questão é tratada hoje em dia? O Laravel ainda possui essa 'desvantagem'? A opção apresentada no vídeo continua sendo a melhor prática?

Ótimo artigo parabéns, mas você não acha que a dependência também ocorre em tudo desde que se use orm? O mesmo pode ocorrer quando se usa entityframework por exemplo. Grande abraço. Além do que nenhum frame tem 100% de garantia que vai durar pra Sempre. O ideal seria fazer igual ao python virar uma fundação por exemplo. Mas você está certo no seu argumento. Grande abraço.

Ótimo video Vinícius!!! Analisando o seu contexto sobre o Active Records dá para entender que ele fere o S (Solid), conforme a implementação no Eloquent ORM.

Adoro o laravel e adoro a forma com que o eloquent funciona. Sobre dizer que usar o eloquent é depender muito do laravel eu não concordo. A partir do momento que vc usa um framework você passa a depender dele, você não vai conseguir migrar uma aplicação symfony para outro framework também.

Pelos comentários vejo que gerou um pouco de crise existencial no pessoal, alguns perguntando se deveriam parar de usar o Laravel, outros perguntando se deveriam parar de usar frameworks, outros perguntando qual o melhor. Eu acredito que o Laravel é bastante poderoso e versátil pela quantidade muito expressiva de pessoas que contribuem diretamente para o projeto ou indireto na forma de componentes. O que o Vinícius mencionou dos pontos que desagrada nele não significa que o framework está condenado e nem que ele não será útil em nenhum projeto. Ao contrário, lendo alguns comentários abaixo o Vinícius menciona algumas situações onde o Active Record faz mais sentido e mais produtivo. É difícil alcancar o nível de senioridade de um dev como o Vinícius, onde ele já viu e usou muita coisa, então, ele consegue com destreza saber o melhor framework (ou nenhum framework) para cada tipo de projeto. Na maioria dos projetos - agora minha opinião - creio que o Laravel irá atender. Só consigo ver projetos muito grandes ou de carácter específicos que ele é menos interessante. Inclusive será sempre excelente para fazer APIs para nossos web apps - onde o Active Record se torna ponto forte novamente.

a única coisa chata é que eu fiz meu sistema no 7 e agora já tá no 9 kk tirando isso é bem bacana, padrão da indústria

Gostei muito da explicação técnica! Obrigado.

Pra mim o grande problema é: depender de implementação do que contrato. E neste cenário, vc poder ter Doctrine, CakeORM, ou outros que implementam Data Mapper, que mesmo assim terá grandes dores quando precisar substituí-los, assim como o Eloquent. Então, independente do que será usado, o melhor caminho é quebrar essa dependência de objetos concretos e depender apenas de interfaces. Parabéns pelo conteúdo!

Vc ta falando ai pra programadores iniciantes né... Perfeitamente possível se livrar dessa dependência do laravel com service/repositorty....

Não entendi a sua fala quando você disse que a classe tem 2 responsabilidades. A classe é um subgrupo de Model certo? pois ela é estendida... O Laravel usa uma abordagem chamada ORM onde ele mapeia cada tabela do banco como um objeto. Consequentemente a classe, que nesse caso é camada de "Entidade (uma representação de persistencia de dados)" é responsável pela sua persistência e outras operações. Onde está a outra responsabilidade?

Muito bom. Seria legal fazer alguns videos sobre pós e contra dos framworks. Eu mesmo uso o codeigniter a algum tempo. Mas nunca parei para pensar sobre esta questão.

Depois de ler 301 comentários e todos os sub comentários aqui, vou dizer que o entendi rsrsrs... Você tem uma filosofia de programação que é desenvolver da forma mais desacoplada possível e principalmente quando se trata do DOMÍNIO. Este último trata das regras de negócio. Trata das entidades da vida real implementadas em código a fim de automatizar uma tarefa do dia-a-dia. O que você mais não gosta no Laravel é obviamente a indução nativa do framework a usar o ORM Eloquent, que utiliza o padrão ActiveRecord. Também há outros motivos como abuso do uso de métodos estáticos e etc. Você não é contra Laravel nem mesmo do ActiveRecord, porém para aplicações de grande porte cuja vida útil pode se estender por décadas, o uso dessa abordagem pode dificultar a migração do Laravel para outro framework no projeto em caso de descontinuidade desse ou qualquer outro motivo. O alto nível acoplamento ou uso disso em excesso no código trás várias dificuldades como manutenibilidade, expansibilidade ou escalabilidade de determinada responsabilidade do DOMÍNIO. ActiveRecord é ruim? NÃO! Também comentou que em projetos cuja responsabilidade é apenas fornecer camada para acesso aos dados, AR é uma ótima escolha. O problema da AR é quando o projeto necessita de uma camada de DOMÍNIO, regras de negócios e etc. Várias pessoas propuseram soluções para usar Laravel com DataMapper, Doctrine, Service/Respository e etc, mas não vale a pena lutar para desacoplar sendo que existem outros frameworks que foram feitos para serem desacoplados e estão aí prontos para serem usados sem precisar desconstruir a filosofia ou abordagem do que já foi utilizado no Laravel. Ao que me parece me referindo a impressão do Dias de Dev em relação ao Laravel é que muita coisa nele foi feita seguindo uma filosofia mais acoplada. Ao invés de lutar e passar trabalho reinventado a roda tentando desacoplar o Laravel, é mais fácil utilizar outros frameworks feito com o padrão DataMapper como Symfony ou Laminas. Ao invés de desmontar um avião e tentar mudar algumas peças para montar um carro, mais fácil comprar um carro que já existe e melhorar ele se necessário. Se você tem uma solução para desacoplar o Laravel, por que não começa desacoplado sem usar o Laravel com plugin ORM não oficial? E mudar o que já está em produção bem acoplado a um bom tempo. Bem é difícil, complexo e seu chefe não vai gostar do investimento (retrabalho*) rsrs. Também resumindo outros comentários DAQUI: - O Laravel tem sido melhorado em suas últimas versões para ser mais desacoplado; - Boatos de que o Doctrine não é 100% compatível em todos os casos com Laravel. O fato dele não ser suportado oficialmente pelo Laravel apoia esses boatos.. - LAMINAS Project é continuação do ZEND (getlaminas.org/); - Versão leve do LARAVEL provavelmente é o LUMEN; # Antes de achar que ele é hater de Laravel, ele da aulas dele kkk

Nenhum framework tem a documentação que o laravel tem, isso fez eu escolhe-lo

Algo que aprende-se com pesquisas, é o diferencial de quando temos uma orientação especializada.

Quanto ao ActiveRecord, só é um problema usando framework né? Se eu mesmo crio a classe Model não tem o problema de acoplamento, já que sou eu mesmo quem dou suporte a ela. Ou eu estou pensando errado? -- ajuda o novato aqui --

Apesar de gostar muito do Laravel essa é a parte que eu também critico. Não o uso do AR, mas ele ser a única opção. Esse pacote de decisões arquiteturais veio do Ruby on Rails. O eloquente poderia ter suporte claro a repository por exemplo e deixar o dev escolher

Qual o melhor framework php na tu visão?

Não é muito a minha praia, mas acredito que essa seja a mesma crítica ao Rails né? Bom. Eu sou muito fã de Laravel e uso desde a versão 4, mas é legal ver uma crítica embasada como a sua! Parabéns Vinícius!

ta e qual a tua solução? eu tentei instalar o symfony e simplesmente não foi

Ruby on Rails tb usa active record.. hehehe..

Ta, mas se eu escolho o framework para desenvolver, depender dele seria um problema? A solução real seria não usar um framework? Mesmo o Symfony, ele não tem forte acoplamento com nenhuma outra camada do projeto?

Caraca!!! Já trabalhei com Zend, Zend2, Cake, o pai do Laravel Fuel, o citado Phalcon(utilizo atualmente)... Mas sempre gostei muito do Laravel desde a sua versão 5. E o Sr. vem com argumentos que são irrefutáveis a me fazer repensar em voltar o Zend2 com Doctrine(Que digasse é um excelente ORM)... Muito bom conteúdo!

Fala mais do Data Mapper, achei muito interessante

Interessante sua abordagem jovem! Fica o like.

eu tenho um sistema de gestão para loteadoras, e a vida desse sistema é pra 15 20 30 anos... eu facilei em ter feito usando Eloquent... mas venho resscrevendo, separando a dominio, do Laravel... de tal forma no futuro, eu precisar trocar de framework, ou simplesmente n usar mais framework, meu dominio ja esteja isolado das bibliotecas... abraço!

Todo framework é uma bengala, te ajuda bastante em vários pontos no caminhar, mas também tem o peso extra a se carregar. Eu gosto do Laravel e de PHP pra mim é o melhor, mas quando se usa por exemplo o Django do Python se percebe uma simplicidade bem maior que no Laravel.

Então não é que você não gosta do Laravel, na verdade você não gosta do Active Record que tem no Eloquent sendo que existem outras formas de fazer como por Repository ou Data Mapper, e você pode usar Doctrine com laravel tranquilamente caso não queira o Eloquent.

Concordo Vinícius a lógica das consultas ficam todas amarradas ao framework.

Preciso ter o domínio preso ao ORM do Laravel? Não. Posso ter o domínio preso ao ORM? Sim, se o projeto for pequeno não vejo problema. Se for grande, aconselho pensar melhor na arquitetura. O ORM do Laravel é um problema? Não. Como separo o domínio do ORM? Em resumo: POPO + Repositories (Ver SOLID, Clean Architecture e DDD) Enfim, Laravel é uma boa ferramenta que usei por muitos anos. Entretanto, não usaria em projetos futuros. Tem coisa melhor por aí que é mais simples de usar. De qualquer forma, ótimo vídeo :)

E o que impede de trocar o Eloquent pelo Doctrine?

Achei que era só eu que pensava assim. Muito bom conteúdo.

trabalho desde a versão 4 aprendi a gostar dele e a usar essas peculiaridades, nas novas versões a unica coisa que me incomodou foi o fato de ter mudado o jeito que trabalha com o front, de resto e muito lindo, sobre isso que falou da depedencia eu entendo demais, ja tive problemas com isso, eu inclusive fiz uma classe extender o model direto nela ao inves de usar a model do laravel, assim tenho mais liberdade nas coisas, e tambem uso bastante o propio query builder dependendo da situacao, inclusive prefiro ele muitas vezes ao inves do Eloquent mesmo

Excelente abordagem! Concordo plenamente com a sua opinião.

No meu projeto laravel, posso utilizar eloquent ou doctrine mudando apenas a variavel de ambiente. Se você tem uma arquitetura bem definida, você não fica preso a nenhuma lib ou framework. Troca igual troca de camisa, kkkkkkkkk. (Nem tanto).

Sobre o projeto depender da model dá para usar um provider que acessa a camadas externa (model) para a aplicação fazer uso desse provider e nunca da model diretamente. Posso estar falando bobeira e por isso to colocando aqui kkk. Assim vou tendo outras visões =D

Vinícius, eu pretendia criar um projeto em Laravel que trabalharia com os dados de uma API também feita em laravel, justamente para utilizar o ORM. Você me recomendaria alterar a minha estratégia para utilizar o doctrine? Já que com essa divisão, eu poderia criar um projeto em Laravel (para fazer uso de rotas por exemplo) e conectar com a minha API que trabalharia com esse ORM do doctrine, seria possível? Agradeço o excelente vídeo ainda mais em uma situação muito propícia para mim!

Top demais vinicius, conteudo de primeira qualidade.

Eu gostei da parte que ele falou que é rarissimas as exceções que te fariam mudar de framework. Eu tenho muitos projetos com Zend, que virou Laminas. Dei uma olhada no Laravel e não curti a disposição de pastas. E esse negocio das Facades não me agradou muito. Essa questão do ORM dele, para quem usa Doctrine, fica meio estranho mesmo. Não me esforcei para aprender Laravel porque eu achei perda de tempo aprender algo para a mesma linguagem que faria as mesmas coisas. Optei por aprender Spring no Java e também alguma coisa do .NET Core e NodeJS. A verdade é que o Laravel é fácil de aprender, fácil de usar... Por isso vem a aceitação da comunidade em peso. E o código do Laravel, é bonito, gostoso de trabalhar. Laravel é produtividade. Se você quer ser produtivo e quer se apaixonar pelo código, vai de Laravel. Como nosso amigo falou ali, quando você conhece a coisa, você muda, deixa ela mais parecido com o seu estilo de trabalho. Parabéns pelo video e parabéns para o pessoal que curte a ferramenta.

Gosto muito da abordagem parecida com o doctrine q o symphony segue de anotações, faz um vídeo falando mais disso se possível :)

Interessante mas quando usamos o repositories com interfaces e contracts a questão do orm eloquent ou querybuilder não faz diferença. Se não quiser usar o eloquente e quiser usar o doctrine, pdo ou outra qualquer forma ok. Estou errado?

Para fazer uma api usando PHP, o que você escolheria ?

E o que você acha do CodeIgniter? ele tem a mesma estrutura neste aspecto que o Laravel??

O maior problema é a responsabilidade dupla a meu ver, sou como o V.D (por que será né? nem aprendi tudo com ele kk) gosto de tudo bem separado, bem abstraído.

Enquanto estive na comunidade PHP, era muito difícil encontrar esse tipo de assunto, e quando achava não tinha um bom argumento, acabava sendo apenas um "faz assim que é melhor" e não convencia, pq só mostrava ser mais complexo/verboso. A menos de um ano eu comecei a estudar .Net Core, que por ser mais utilizado por grandes empresas com grandes projetos, acabam tendo que lidar com esses problemas apontados no vídeo, e a comunidade do C# já tem esses conceitos bem mais difundido que a comunidade do PHP. Não estou fazendo comparação de linguagem ou comunidade, mas e sim informando que outras comunidades possuem outras visões, e isso pode agregar muito. Hoje eu não me vejo fazendo uma aplicação Laravel com o domain/infrastructure acoplado ao framework.

Voce acha que o symfony serve para uma API Rest ou Acha que é over Engineering? Eu estou iniciando um novo projeto e estou entre slim, symfony e laravel. Tambem nao sou fã do active record, inclusive fiz algumas apis com Lumen usando Doctrine para evitar o uso. Fui hoje no site da Laravel e eles falam para nao usar mais o Lumen, ai acabei desencanando de vez. Ai estou com essa duvida de qual escolher

Cara, acabei achando seu vídeo aqui enquanto pesquisava sobre o Laravel, vim pra conhecer uns pontos negativos rsrs e vc acabou chegando num ponto muito importante pra mim aqui... Eu já estou acostumado a utilizar o Doctrine, e já estava pensando em fazer algo com o Laravel mas mantendo minhas entidades do Doctrine. Isso não é possível? Fazer um projeto no Laravel porém utilizando doctrine ao invés do Eloquent??

Não sou um desenvolvedor com muita experiencia, mais se adotar o partner repository, não resolveria essa questão do Eloquent?

Bem legal o video Dias, parabens pelo trabalho.

Professor, sou leigo ainda, mas ainda sim quero fazer uma pergunta. Neste cenário que você apresentou, o DAO feito na "unha" seria a melhor saída? Além claro do Doctrine conforme apresentado.

Tem alguma sugestão de framework?