Lumen: Routes, Controllers e Models
Tags: lumen, php
Published: 2023-10-16 12:03:41


![](https://cdn-images-1.medium.com/max/2560/1*T6Ll8gHDT9WD5JN_pKDc_A.jpeg)

Vamos falar de algumas coisas bem simples dentro do mundo de qualquer framework bem estruturado, que é as Routes, Controllers e Models. Muita coisa gira em torno disso, assim sendo, é bom levarmos em consideração a real função de cada um destes personagens para uma melhor organização e utilização.

Para quem não pegou o post anterior
[**Lumen: Ensinando comandos para nosso terminal artisan**](https://dev.to/henriqueweiand/lumen-ensinando-comandos-para-nosso-terminal-artisan-5393)

### Routes

No Lumen até a versão 5.8.* as rotas se encontram no seguinte diretório

    /routes/web.php

Como o próprio nome já se auto explica, rotas são arquivos simples onde realizarmos a organização daqueles que serão nossa porta de acesso externa ao mundo, seja para processar algum input de dados ou para seder alguma informação.
>  Como a nossa proposta inicial é um CRUD através de uma aplicação que serve endpoints, vamos levar aplicar os bons padrões REST para endpoints, ok? ou seja, POST, GET, PUT, DELETE entrarão em cena!

inicialmente temos o seguinte conteúdo
{% gist https://gist.github.com/henriqueweiand/54b54c8583118a4fe4e7a16236fed16d.js %}
Não vou entrar em mais detalhes de configuração do *routes/web.php* pois ele vai ser configurado pelo comando seguir.

### Criação dos scripts Controllers, Models, Migrations, Routes e Factory

Vamos executar o seguinte comando na pasta do projeto /lumen

    php artisan wn:resource messages "user_id;integer;unsigned;required; description;text;required;" --add=timestamps

Este comando via lib **wn/lumen-generators **ira criar

* Routes

* Controller

* Model

* Migration

* Factory

Que ótimo! não? Mas confesso para você que não peguei exatamente a como passar os **fields** para a criação de maneira automática ainda, então deixei os fields simples para fazermos a manutenção posterior.

### ATENÇÃO

o **wn/lumen-generators **não é perfeito, e digamos que ele ainda esta baseado em algumas versões de Laravel que faziam o uso de certas variáveis com nomes diferentes das atuais, então vamos fazer uma correção que o comando acima faz, abra então o

    /lumen/routes/web.php

e mude as variáveis $app para $router !

Precisamos ajustar também um detalhe por aqui. Não vou detalhar muito nesse momento mas vamos mudar o nome dos métodos criados pelo WZ e deixar o resultado do nosso *web.php* da seguinte maneira
{% gist https://gist.github.com/henriqueweiand/8db5123640b7b269b459d549a838d287.js %}
Aproveitei para agrupar as rotas :)

Depois de rodar, vamos excluir um script existente em

    /lumen/app/User.php

E vamos executar o comando para a criação das coisas com

    php artisan wn:resource users "name;string;required; lastname;string;required; email;string;required; telephone;string;required;" --add=timestamps

Assim como o comando anterior, este fez a criação de todos os arquivos para User.
>  Não esqueça de fazer a correção no /routes/web.php conforme feito no passo dos messages

### Controllers

Com a execução dos comandos já foram criados automaticamente dois controllers na pasta /lumen/app/Http/Controllers chamados

* MessagesController

* UsersController

Vamos fazer algumas mudanças muito semelhante em ambos para que seja mais apresentável, por exemplo com *UsersController.php*
{% gist https://gist.github.com/henriqueweiand/e8754f6476d7441b7b94b54ead80cf0c.js %}
E *MessagesController.php*
{% gist https://gist.github.com/henriqueweiand/ec1e5bfb3f294fce079d590b761bc425.js %}
Nestes arquivos estamos definindo o que vai acontecer quando chegar la no route e chamar o Controller. Lembre que como estamos utilizando a **Trait** nossos dois scripts meio que herdam os métodos anteriores porem no caso do Messages ele sobre escreve o index pois o mesmo deve funcionar de forma diferente da padrão da Trait assim como temos um outro método *show_user_messages*
>  Ainda não conseguimos testar pois precisamos configurar outras coisas

### Models

Models são os responsáveis pela manipulação dos dados mais em uma camada eu diria mais próxima ao banco, pois seguindo a estrutura padrão do Laravel, ele determina os campos, aqueles que podem ser visto, editados, relacionamentos entre tabelas e outras coisas a mais :)

No nosso caso, quando utilizamos o **wn/lumen-generators **o própria lib criou os models em /lumen/app chamados *Messages.php *e *Users.php* porem precisamos fazer algumas alterações em ambos pois como comentei laa em cima, o comando de criação dos resources eu não peguei muito bem então vai ser necessário algumas alterações tanto aqui quanto nas migrations posteriormente. Pois bem vamos lá em *Users.php*
{% gist https://gist.github.com/henriqueweiand/284b53dad26dc412e74e05d73ad0ab00.js %}
Em *Messages.php*
{% gist https://gist.github.com/henriqueweiand/2fc623f8c29acff5a4ac20a176a801a9.js %}
Como eu comentei, fizemos um model onde em $fillable se trata dos campos alteráveis. $rules se trata das regras onde vamos aplicar o validator do Laravel e no caso do messages temos um método user que se trata de uma relação entre tabelas **messages** ← → **users**

### Migrations

Para quem não conhece, migrations são os scripts de automação para a criação da estrutura do banco de dados.
>  Mas porque usar?

Eu considero muito importante apesar de notar que não é uma pratica tão real no cenário do mercado por empresas que passei, mas enfim, considero importante pois vamos supor que hoje seu sistema roda com um banco de dados **mysql** e em uma linda manhã de segunda seu chefe mude de ideia e queria que tudo rode em **postgres.**

![](https://cdn-images-1.medium.com/max/2000/1*xuIOiNgXM0YK-lhaf95Hcg.gif)

Sim, pode acontecer, mesmo que meio remoto, mas acontece. Ok, mas fora esse cenário, pense em deixar tudo mais rápido possível para que qualquer pessoa, lugar ou infra consiga subir o ambiente e sair programando… Essa ideia começa a se tornar atrativa, não?

Como nosso projeto já utiliza docker em termos de automação, vamos deixar o projeto mais "foda" ainda (desculpe o palavreado), com isso vou abordar **Migrations.**

Continuando…

Quando usamos o comando resources la do wz ele criou também duas migrations localizadas na pasta

    /lumen/database/migrations

o nome dos arquivos variam pois ele cria com base no timestamp da geração afim de seguir uma sequencia na execução das mesmas, então tente criar as tabelas em uma lógica correta de relacionamento entre tabelas (comece pelas pontas geralmente), os meus são esses aqui

![](https://cdn-images-1.medium.com/max/2000/1*hTrrG4aGLnFvf9updL2bvQ.png)

Assim como eu disse das alterações do model acima, pois não usei o comando correto, vamos fazer a alteração também nesses caras ai, começando com o users, deixando o da seguinte maneira
{% gist https://gist.github.com/henriqueweiand/cee5bc2f822651d48526738c3af5a52a.js %}
Depois o de messages
{% gist https://gist.github.com/henriqueweiand/27f779dfc9b481c5cac83ee33aebb8e1.js %}
Veja que incrível! É bem simples de ler o código e ver que estamos especificando os campos de uma tabela e seus respectivos campos assim como as relações.

### Factory

Por fim, mas não menos importante no cenário de migrations e testes, vamos alterar um cara localizado em

    /lumen/database/factories/ModelFactory.php

Deixando da seguinte maneira
{% gist https://gist.github.com/henriqueweiand/bb7e208194de7a4236bcdac3807fa9e7.js %}
A **factory** será utilizada para a realização dos testes principalmente… pois facilitará para que nosso teste seja inteligente em realizar alguns processos de criação de maneira mais centralizada.

Agora vamos ver se as coisas funcionam, não é. Deixe seu docker rodando e se como eu não tem os containers de pé, ai só rodar tbm um docker-compose up -d no diretório raiz do projeto, la onde esta o *docker-compose.yml*

![](https://cdn-images-1.medium.com/max/2560/1*RbIJnA8Tiaseb-5EIZqzWw.gif)

Assim que subir, use uma ferramenta de sua escolha para abrir o banco de dados com os dados de acesso que definimos no docker-compose.yml

    MYSQL_ROOT_PASSWORD: root

    MYSQL_DATABASE: lumen

![](https://cdn-images-1.medium.com/max/2560/1*fFDf5Ot1wYeRMCQFS_P4Eg.gif)

Ainda não temos nada de tabelas, então vamos rodar o seguinte comando no terminal na pasta do projeto

**LEMBRETE:** tenha certeza que seu arquivo .env esta com os dados de conexão se não igual parecido com este
{% gist https://gist.github.com/henriqueweiand/8bf574850b22b4c3a8ea820d51dd5faf.js %}
E então rodamos o comando

    docker exec -it php php /var/www/html/artisan migrate

Veja que lindo

![](https://cdn-images-1.medium.com/max/2000/1*04oGAlSAbQDjUm4RIpq8LA.png)

Assim como

![](https://cdn-images-1.medium.com/max/2000/1*g5pKbl_UFLFKEuevAMiiRw.png)

Finalizamos pessoal! Finalizamos a parte mais extensa… agora vamos falar de coisas que ao meu ver são mais simples. Mas apenas para lembrar já fizemos:

configuração do ambiente com docker, subimos um lumen e instalamos as dependências, configuramos routes, models, controllers, factory e rodamos a migration para subir o banco. Nos próximos posts vamos ver as coisas funcionando mais de perto ainda com seus devidos endpoints.