Laravel Controller . Desenvolvendo a lógica da sua aplicação

Laravel Controller

Laravel Controller . Imagem Ilustrativa

Nos primeiros artigos desta série trabalhei massivamente para aprender e desenvolver o máximo que pude no tratamento dos dados do banco de dados. Fui desde a criação da estrutura do banco com as migrations até a criação de respostas RESTful através dos resources. Agora chegou a hora de desenvolver a lógica da aplicação com o Laravel Controller.

Partindo do ponto que você já conhece sobre o MVC, fica claro que o controller não se trata de uma exclusividade do Laravel. Mas, como todo framework, o Laravel Controller tem sua forma de trabalhar. Em sua documentação, podemos ver que a função dos Controllers é organizar e agrupar requests relacionadas, manipulando sua lógica em uma única classe.  O que eles querem dizer é que tiraremos toda a complexidade de código que inicialmente estaria na closure das rotas.

Criando seu primeiro Laravel Controller

Para iniciar o trabalho primeiramente temos que criar o Controller que iremos trabalhar. Voltando ao nosso exemplo prático, vou montar o Controller para criar os endpoints dos nossos produtos. Para isto utilizarei o php artisan.

Este comando é o mais indicado pois você terá a estrutura e as dependências todas montadas pelo próprio Laravel. Isto pode evitar muita dor de cabeça. Bem, se tudo der certo você terá o seguinte arquivo dentro da sua pasta Http/Controllers.

O Laravel Controller sempre extende a classe Controller padrão do Laravel. Assim, você já terá convenientemente métodos comuns como por exemplo o Middleware.

Criando os métodos do Controller

Para todo CRUD básico nós teremos 7 funções que resolverão em 7 rotas diferentes. Criarei elas aqui dentro do padrão do Laravel com os nomes:

  • index – Lista os dados da tabela
  • show – Mostra um item específco
  • create – Retorna a View para criar um item da tabela
  • store – Salva o novo item na tabela
  • edit – Retorna a View para edição do dado
  • update – Salva a atualização do dado
  • destroy – Remove o dado

Dependendo do seu projeto, você consegue economizar aqui a tela do create e do edit. No mais, o CRUD vai exigir pelo menos as 5 rotas de interação com a Model. No meu caso serão 6 pois coloquei a adição de produtos junto com a listagem. Assim, nosso Laravel controller ficará como abaixo:

Uma observação especial para os métodos show(), edit(), update() e delete(). Nestas funções você pode ver que temos parâmetros vinculados para repassarmos paras as views ou para salvar no banco de dados. O $product irá injetar a instância de Product com o dado que será passado na rota (GET) ou POST. Para entender melhor vamos seguir e registar as rotas para este controller.

Registrando as rotas

Agora que as funções estão estruturadas é hora de montar os endpoints. Para isto utilizarei o arquivo web.php que está na pasta routes. Este arquivo é responsável por rotear o caminho da request para a função correta no controller e retornar o resultado. Abaixo segue o meu exemplo.

Aqui utilizei 4 métodos de request para executar cada ação. GET e POST que são os mais comuns, e PATCH e DELETE que são respectivamente para atualização e remoção de dados.

Você também vai reparar que nas quatro últimas rotas temos a palavra { product }. Lembra-se da injeção automática da instância Product? Então… a instância de Product será o model referente ao id do produto que você passar nesta rota. Assim, se você quiser deletar o produto de id 1, basta passar pela URI  ‘products/1’, com o método delete, e implementar a deleção no Laravel Controller.

Veja acima como ficou simples deletar um produto. A instância já possui todas as referências do model do produto 1. Assim, é só executar o comando delete do Eloquent que ele faz o resto sozinho.

Implementando os métodos de CRUD no Laravel Controller

Já que configuramos as rotas para cada método do controller e além disso implementamos o método DELETE vamos aos próximos métodos. Começarei pelos métodos de Visualização, pois Eles são simples métodos que vão receber os dados dos models e repassar para as suas respectivas Views.

Vejam que em edit eu fiz também uma busca dentro da model Product_lines. Isto porque eu vou precisar de todas as linhas de produto caso eu queira mudar este produto de linha.

Por fim, vamos aos  métodos de escrita, store e update

Salvando dados no Banco de dados

Se você leu esta série desde o começo, verá que esta parte já havia sido feita, em parte, no artigo Simplificando models no Laravel. Na função store() eu fiz o mass assignment e na função update setei cada dado enviado pela Request na instância do model Product e então utilizei o save() para efetivar a mudança no banco de dados.

O código final ficou assim:

Conclusão

O Laravel Controller é onde manipulamos a lógica de tratamento das requisições recebendo os dados do model e transmitindo-os para a view. O Laravel Controller abstrairá toda a complexidade da rota que, como já diz o nome, apenas roteará a Request feita para sua devida lógica.

Este é apenas um artigo inicial para sobre Laravel controller nele ainda podemos implementar validações de dados e middlewares que garantirão segurança e estabilidade ao projeto.

Felipe Moraes
Felipe Moraes

Desde pequeno eu adorei tecnologia e este sentimento me fez estudar e trabalhar com desenvolvimento, design de interfaces e interação. Esta vontade de melhorar e aprender com a tecnologia me fez estar aqui na DialHost desde 2012.

Parte I – Introdução aos frameworks

Introdução a Frameworks

Diagrama ilustrativo sobre a interseção de funcionalidades comuns em aplicações semelhantes

Ao pé da letra, framework é uma abstração de soluções prontas para problemas comuns. Por exemplo, um e-commerce procura um conjunto de ferramentas que ajudem no seu funcionamento, como carrinho de compras, cálculo de frete, etc. Cada framework tem suas características e, por consequência, vantagens e desvantagens.

As maiores vantagens de fazer uso de Framework são:

  • Desenvolvimento rápido.
  • Não precisa de reinventar a roda, existem várias bibliotecas prontas.
  • As bibliotecas geralmente são bem testadas, documentadas e bem escritas.
  • A segurança é maior. Geralmente os frameworks já cuidam dos filtros de XSS, SQL Injection, session hijacking.
  • Seguem um padrão de escrita, como PSR-0, 1, 2… Isso torna o código mais limpo e legível.

Por outro lado, existem desvantagens:

  • A curva de aprendizado é alta, demora um pouco para aprender como usá-los.
  • Para criar novas funcionalidades você precisa de um tempo maior para aprender como o Framework funciona.
  • Se existe algum exploit ou falha de segurança, sua aplicação precisa esperar um patch da equipe que desenvolve o Framework.

Diferenças entre frameworks full stack e non-full stack.

Frameworks full stack obrigam você utilizar todo ecossistema deles, mesmo que seja apenas para usar uma ferramenta. Os non-full stack ou modulares, deixam a critério do desenvolvedor escolher o que vai usar e ainda existe a possibilidade do desenvolvedor usar as bibliotecas do framework em projetos avulsos.

Composer.phar

O grande hit dos frameworks modulares atualmente é Composer. Ele é um gerenciador de dependências, não de pacotes (embora lide com as bibliotecas e os pacotes). O desenvolvedor escolhe quais são as dependências do projeto e ele se encarrega de instala-las e mantê-las atualizadas. A ideia do Composer mesmo sendo brilhante, não é nova, ele foi inspirado no npm (node.js) e bundler (ruby). Todas as dependências ficam em um repositório chamado Packagist, que na verdade é um agregador de repositórios.

Os frameworks modulares utilizam o máximo do que o Composer pode proporcionar. Ele permite que o desenvolvedor “instale” os módulos (pacotes) através dele, tornando muito mais dinâmico o uso dos frameworks modulares, hoje pode-se usar a classe de Rotas do framework A e usá-la no framework B, tornando-os quase plug-and-play.

Concluindo

A escolha de qual framework usar é muito complicada, vários fatores devem ser levados em consideração, existem micro-frameworks específicos para criação de APIs, outros são específicos para e-commerce, blog, etc. Não existe solução perfeita, cada projeto precisa ser levado em conta qual tecnologia usar. Muitas vezes o uso de framework dificulta a implementação de novos recursos, ele deve ser utilizado a favor do projeto, não contra. Uma vez que ele gera mais problemas do que facilita já deve ser cogitada a ideia da troca de framework.

Referências

  1. http://stackoverflow.com/questions/635007/framework-what-is-a-php-framework
  2. http://stackoverflow.com/questions/1506782/full-stack-versus-non-full-stack-mvc-php-frameworks-whats-the-difference
  3. https://getcomposer.org/doc/00-intro.md

 

Assine o plano de hospedagem que melhor atende suas necessidades a partir de R$8,42/mês*

Pedro Maia
Pedro Maia

Desenvolvedor front-end na DialHost, estudante de Sistemas de Informação na PUC Minas. Apaixonado por desenvolvimento de aplicações web e bacon.