Motivos para não usar mais Laravel

Esse texto é uma adaptação e análise do artigo do Niklas Schollhorn no Medium. Nesse texto o autor descreve os principais motivos que o levaram a abandonar o framework laravel.

Logo no resumo e introdução o autor afirma que o objetivo não é converter outras pessoas a largarem o framework, pois ele mesmo utilizou durante muitos anos e afirma que é difícil encontrar alguma ferramenta semelhante ao laravel, que oferece comandos de console, gerador de classes, códigos prontos como autenticação entre outros. O objetivo do autor é meramente apresentar os pontos que levaram ele a deixar de utilizar o framework. Um argumento muito utilizado é que quando os projetos se tornam maiores, acaba sendo muito complicado manter o projeto e acrescentar novos recursos, segundo o autor isso acaba se agravando por conto do próprio PHP não ser muito bem arquitetado e estruturado.

Eloquent ORM

Ao analisar o eloquent ORM o autor descreve um conjunto de funcionalidades legais e úteis, mas que torna o código desnecessariamente complexo e impede que a IDE analise o código corretamente.

O Active Record ORM realmente “salva” o desenvolvedor de ter que escrever mais código. Para fazer isso, ele permite que o desenvolvedor insira muito no modelo que não pertence a ele, que não foi o modelo criado. É possível notar que não há propriedades no modelo. Isso parece irrelevante, mas tudo é injetado “magicamente” na classe lendo metadados da tabela.

De fato o Laravel utiliza os métodos __call() e __callStatic() para tratar métodos como o estático e conhecido all(). Segundo o autor a não definição desses métodos e a criação de forma “mágica” dificulta a compreensão de novos desenvolvedor e a análise estática fica mais difícil também.

Para finalizar, o Eloquent usa seus modelos para várias responsabilidades. Ele contém os dados do banco de dados, que é  o que os modelos normalmente fazem, mas também tem lógica de filtragem, talvez classificação e ainda mais.

Global Helpers

Helpers são pequenas funções globais que ajudam o programador a realizar chamadas que são corriqueiras, para evitar a replicação de código. Dificilmente essas funções causam algum problema na aplicação, mas quando utilizadas em grande número, podem poluir o namespace global da aplicação. Vale lembrar que muitos dos helpers que são implementados acabam sendo desnecessários e por esse motivo que o autor critica fortemente essa prática.

Um exemplo de prática que é a utilização do request() que basta ser adicionado na chamada do método que o objeto já vai ser criado e a utilização do helper torna-se dispensável.

uso com o helper
uso com injeção de dependência

Com uma breve análise podemos concluir que os helpers devem ser utilizados moderadamente e somente quando for realmente necessário.

Facades

Outra prática muito criticada é o uso de Facades, novamente pro tratar de chamadas que são escritas com métodos mágicos, o que dificulta o autocomplete e compreensão da IDE. O autor reconhece que existem inúmeros plugins que possuem esse objetivo e tornam o desenvolvimento mais simples, mas critica dando como exemplo o sinfony que possui uma arquitetura muito mais bem elaborada e torna dispensável a utilização de plugins de terceiros para esse fim.

Novamente como solução é possível substituir por injeção de dependência. Dessa forma o trecho de código passa a ter um objeto real e métodos reais.


Novamente como solução é possível substituir por injeção de dependência. Dessa forma o trecho de código passa a ter um objeto real e métodos reais.

Muitas pessoas acabam abusando da utilização de chamadas de injeção de dependência e isso também não é uma boa prática. Se esse grande número de chamadas está no método construtor por exemplo, pode ser um indício que a classe em questão pode estar sobrecarregada e como muitas responsabilidades atribuídas a ela.

Conclusão do autor original

A abordagem do Laravel para tornar tudo o mais fácil possível é boa. Mas é difícil se dar bem quando seus aplicativos se tornam mais avançados. Eu prefiro suporte IDE impressionante, digitação mais forte, objetos reais e boa engenharia. Eu posso até voltar para o Laravel quando eu quiser escrever um aplicativo menor.

Muitos dos meus pontos não são apenas culpa do Laravel. Eu poderia trocar as partes que eu não gosto, por exemplo, o ORM. Mas, em vez disso, vou apenas trocar o kit de ferramentas, onde os padrões se ajustam melhor às minhas necessidades. Não vejo sentido em usar um framework em que eu tenha que gastar mais tempo evitando armadilhas que ele cria para engenharia ruim do que desenvolvendo meu aplicativo. Outras estruturas e ferramentas vêm com padrões melhor projetados e menos mágica.

Fonte do texto analisado: https://medium.freecodecamp.org/moving-away-from-magic-or-why-i-dont-want-to-use-laravel-anymore-2ce098c979bd