Por que devo usar a estrutura do Laravel

Por que devo usar a estrutura do Laravel

Nos primeiros dias da web dinâmica, escrever um aplicativo da web parecia muito diferente do que hoje. Os desenvolvedores foram responsáveis ​​por escrever o código não apenas para a lógica de negócios exclusiva de nossos aplicativos, mas também para cada um dos componentes que são tão comuns entre os sites - autenticação do usuário, validação de entrada, acesso ao banco de dados, modelos e mais.

Hoje, os programadores têm dezenas de estruturas de desenvolvimento de aplicativos e milhares de componentes e bibliotecas facilmente acessíveis. É um refrão comum entre os programadores que, quando você aprende uma estrutura, três estruturas mais recentes (e supostamente melhores) apareceram com a intenção de substituí -la.

"Só porque está lá" pode ser uma justificativa válida para escalar uma montanha, mas há melhores razões para optar por usar uma estrutura específica - ou usar uma estrutura. Vale a pena fazer a pergunta: por que estruturas? Mais especificamente, por que Laravel?

Por que usar uma estrutura?

É fácil ver por que é benéfico usar os componentes individuais ou pacotes, que estão disponíveis para desenvolvedores de PHP. Com os pacotes, outra pessoa é responsável por desenvolver e manter uma parte isolada de código que tem um trabalho bem definido e, em teoria.

Estruturas como Laravel-e Symfony, Silex, Lumen e Slim Prepackage uma coleção de componentes de terceiros, juntamente com a estrutura personalizada “cola”, como arquivos de configuração, provedores de serviços, estruturas de diretório prescritas e botas de aplicação de aplicação. Portanto, o benefício de usar uma estrutura em geral é que alguém tomou decisões não apenas sobre componentes individuais para você, mas também sobre Como esses componentes devem se encaixar.

“Eu vou apenas construir isso sozinho”

Digamos que você inicie um novo aplicativo da web sem o benefício de uma estrutura. Por onde você começa? Bem, provavelmente deve rotear as solicitações HTTP, então agora você precisa avaliar todas as libeias de solicitação e resposta HTTP disponíveis e escolher uma.

Então um roteador. Ah, e você provavelmente precisará configurar alguma forma de Arquivo de configuração de rotas. O que sintaxe deve usar? Para onde deveria ir? A respeito controladores? Onde eles moram e como estão carregados?

Bem, você provavelmente Precisa de uma injeção de dependência contêiner para resolver os controladores e suas dependências, mas qual?

Além disso, e se você reservar um tempo para responder a todas essas perguntas e criar seu aplicativo com sucesso - qual é o impacto no próximo desenvolvedor?

E quando você tem quatro aplicativos baseados em quadros personalizados, ou uma dúzia, e você deve se lembrar de onde os controladores vivem em cada um, ou qual é a sintaxe de roteamento?

As estruturas de consistência e flexibilidade abordam esse problema, fornecendo uma resposta cuidadosamente considerada para a pergunta “Qual componente devemos usar aqui?”E garantir que os componentes específicos escolhidos funcionem bem juntos. Além disso, as estruturas fornecem convenções que reduzem a quantidade de código que um desenvolvedor novo no projeto precisa entender - se você entender como o roteamento funciona em um projeto de Laravel, por exemplo, você entende como ele funciona em todos os projetos de Laravel.

Quando alguém prescreve rolando sua própria estrutura para cada novo projeto, o que está realmente defendendo é a capacidade de controlar o que faz e não entra na fundação do seu aplicativo.

Isso significa que as melhores estruturas não apenas fornecerão uma base sólida, mas também oferece a liberdade de personalizar para o conteúdo do seu coração.

Uma breve história de estruturas da Web e PHP

Uma parte importante de poder responder à pergunta “Por que Laravel?”Está entendendo a história de Laravel - e entendendo o que veio antes dela. Antes do aumento da popularidade de Laravel, havia uma variedade de estruturas e outros movimentos no PHP e em outros espaços de desenvolvimento da Web.

Rubi nos trilhos

David Heinemeier Hansson lançou a primeira versão do Ruby on Rails em 2004, e tem sido difícil encontrar uma estrutura de aplicativos da web desde então isso não foi influenciado por Rails de alguma forma.

O Rails popularizou o MVC, APIs JSON RESTful, Convenção sobre Configuração, Recordado Ativo e muitas outras ferramentas e convenções que tiveram uma influência profunda na maneira como os desenvolvedores da Web abordaram seus aplicativos - especialmente no que diz respeito ao rápido desenvolvimento de aplicativos.

O influxo de estruturas de PHP

Ficou claro para a maioria dos desenvolvedores que os trilhos e estruturas de aplicativos da web similares foram a onda do futuro, e as estruturas de PHP, incluindo aqueles que imitam os trilhos, começando a aparecer rapidamente.

Cakephp foi o primeiro em 2005, e logo foi seguido por Symfony, CodeIgniter, Zend Framework e Kohana (um bifurário CodeIgniter).

Yii Chegou em 2008, e aura e Slim em 2010. 2011 trouxe FuelPhp e Laravel, ambos não eram ramificações de CodeIgniter, mas propostas como alternativas. Algumas dessas estruturas eram mais trilhos, concentrando-se em mapeadores de objetos relacionados ao banco de dados (ORMS), estruturas de MVC e outras ferramentas direcionadas ao desenvolvimento rápido. Outros, como Symfony e Zend, focaram mais em padrões de design corporativo e comércio eletrônico.

O bom e o mal do Codeigniter

CakePHP e CodeIgniter foram as duas estruturas PHP iniciais que foram mais abertas sobre quanto sua inspiração foi extraída de Rails. O Codeigniter subiu rapidamente à fama e em 2010 foi sem dúvida o mais popular das estruturas PHP independentes.

O Codeigniter era simples, fácil de usar e ostentava documentação incrível e uma comunidade forte. Mas o uso da tecnologia e dos padrões modernos avançou lentamente e, à medida que o mundo da estrutura crescia e as ferramentas avançadas do PHP, o Codeigniter começou a ficar para trás em termos de avanços tecnológicos e recursos prontos para a caixa.

Ao contrário de muitas outras estruturas, o Codeigniter foi gerenciado por uma empresa e eles demoraram a alcançar o PHP 5.Recursos mais recentes de 3, como namespaces e os movimentos para o Github e posterior compositor. Foi em 2010 que Taylor Otwell, O criador de Laravel, ficou insatisfeito o suficiente com o CodeIgniter que ele partiu para escrever sua própria estrutura.

Laravel 1, 2 e 3

O primeiro beta de Laravel 1 foi lançado em junho de 2011 e foi escrito completamente do zero. Apresentava um ORM personalizado (eloqüente); roteamento baseado em fechamento (inspirado em Ruby Sinatra); um sistema de módulo para extensão; e ajudantes para formas, validação, autenticação e muito mais.

Mais tarde, o Laravel 4 e o Laravel 5 vieram e mudaram o jogo inteiro.

O que há de tão especial no Laravel?

Então, o que diferencia o Laravel? Por que vale a pena ter mais de uma estrutura PHP a qualquer momento? Todos eles usam componentes de Symfony de qualquer maneira, certo? Vamos falar um pouco sobre o que faz do Laravel “tick.”

A filosofia de Laravel

Você só precisa ler os materiais de marketing e Readmes para começar a ver seus valores. Taylor usa palavras relacionadas à luz como "iluminado" e "faísca.

E então existem os estes: “Artesãos?' "Elegante?'Além disso, estes: “Breath of Fresh Air." "Novo começo.”E finalmente:“ Rapid.”“ Velocidade de urdidura.Os dois valores mais fortemente comunicados da estrutura são aumentar a velocidade e a felicidade do desenvolvedor.

Taylor descreveu a linguagem 'Artisan ”como intencionalmente contrastava contra valores mais utilitários. Você pode ver a gênese desse tipo de pensamento em sua pergunta de 2011 no StackexChange (http: // bit.ly/2dt5kms) em que ele afirmou: “Às vezes eu passo uma quantidade ridícula de tempo (horas) agonizando sobre fazer o código parecer bonito” - Apenas por uma melhor experiência de olhar para o próprio código.

E ele costuma falar sobre o valor de tornar mais fácil e rápido para os desenvolvedores levarem suas idéias para serem concretizadas, livrando -se de barreiras desnecessárias para criar ótimos produtos. Laravel está, em sua essência, sobre equipar e possibilitar desenvolvedores. Seu objetivo é fornecer código e recursos claros, simples e bonitos que ajudem os desenvolvedores a aprender, iniciar e desenvolver e escrever código simples, claro e durar.

O conceito de direcionar desenvolvedores é claro em materiais de Laravel. “Desenvolvedores felizes fazem o melhor código” está escrito na documentação.

“Desenvolvedor Felicidade do download para implantar” foi o slogan não oficial por um tempo. Obviamente, qualquer ferramenta ou estrutura dirá que deseja que os desenvolvedores sejam felizes. Mas ter a felicidade do desenvolvedor como uma preocupação primária, e não secundária, teve um enorme impacto no estilo de Laravel e no progresso da tomada de decisão. Onde outras estruturas podem ter como alvo a pureza arquitetônica como objetivo principal, ou compatibilidade com os objetivos e valores das equipes de desenvolvimento corporativo, o foco principal de Laravel é servir ao desenvolvedor individual.

Como o Laravel alcança a felicidade do desenvolvedor

Só dizendo que você quer fazer os desenvolvedores felizes é uma coisa. Fazer isso é outro, e exige que você questione o que em uma estrutura provavelmente deixará os desenvolvedores infelizes e o que é mais provável que os faça feliz. Existem algumas maneiras pelas quais Laravel tenta facilitar a vida dos desenvolvedores.

Primeiro, o Laravel é uma estrutura rápida de desenvolvimento de aplicativos. Isso significa que se concentra em uma curva de aprendizado superficial (fácil) e em minimizar as etapas entre iniciar um novo aplicativo e publicá -lo. Todas as tarefas mais comuns na criação de aplicativos da Web, desde as interações de banco de dados a autenticação e filas e email para armazenamento em cache, são simplificados pelos componentes que Laravel fornece.

Mas os componentes de Laravel não são ótimos por conta própria; Eles fornecem uma API consistente e estruturas previsíveis em toda a estrutura. Isso significa que, quando você está tentando algo novo em Laravel, é mais do que provavelmente vai acabar dizendo: “... e apenas funciona?'

Isso não termina na própria estrutura também. O Laravel fornece um ecossistema inteiro de ferramentas para criar e lançar aplicativos. Você tem propriedade e manobrista para desenvolvimento local, forja para gerenciamento de servidores e enviado para implantação avançada.E há um conjunto de pacotes complementares:

  • Caixa - para pagamentos e assinaturas
  • Eco - para websockets
  • Scout - para pesquisa
  • Passaporte - para autenticação da API
  • Socialite - para login social
  • Spark - para bootstrap seu saas.

Laravel está tentando tirar o trabalho repetitivo dos empregos dos desenvolvedores para que eles possam fazer algo único.

“Trechos de - Livro do Laravel Up & Running”