Do not speak Portuguese? Translate this site with Google or Bing Translator
Laravel: anatomia de minhas aplicações

Posted on: August 29, 2019 08:16 AM

Posted by: Renato

Categories: PHP Laravel

Views: 470

POR VEDOVELLI · 10 DE JULHO DE 2015

 

 

 

 

1. app/Http/routes.php – Rotas são as responsáveis por receber as solicitações e as informações providas pelo usuário. Após ter conhecimento da natureza da solicitação, as rotas pedem ajuda aos Controllers, que são mais “velhos de casa” e conhecem os caras que resolvem as questões. As solicitações feitas às rotas são Requisições HTTP e normalmente são do tipo GET ou POST. Se sua app também funciona como uma API RESTful, então as requisições também podem ser PUT, DELETE e HEAD.

 

2. app/Http/Controllers/ – São os caras que conhecem todo mundo e que, apesar de populares, são preguiçosos e sempre delegam a execução dos pedidos das rotas a outras entidades. Um exemplo: ao receber de uma rota a solicitação de uma lista de produtos, o ProductController através de seu método index() pede para que o ProductRepository vá buscar a lista de produtos e a entregue à rota, que aguarda ansiosamente o resultado da requisição GET. Eles também conhecem os caras que validam a informação (FormRequests), conhece o cara que manda e-mails transacionais (o MailService.php) e até mesmo o cara que adiciona um e-mail numa lista suspeita dum serviço de nome estranho (MailChimpService.php). Os controllers são OS CARAS!

 

3. app/User.php – quando uma nova app Laravel é criada, este cara vem junto com os outros arquivos. Trata-se de um Model solitário que só foi criado para atender a uma funcionalidade da qual o Taylor não gosta mais: o scaffolding de Login. =(

 

Mas sua presença nos dá uma pista de onde nossos demais models serão armazenados. Os models são os garotos do almoxarifado e seu papel é localizar a informação está guardada nas prateleiras do banco de dados. Os models são meio introspectos e geralmente não gostam de ver a cara da rua. Não só isso mas num passado longínquo eles tretaram com os controllers e desde então não conversam mais. Nem na festa de final de ano da firma. Os models agora são os melhores amigos dos repositórios, sempre sábios e na deles.

 

Os models são cheios de recursos e basta dar a eles pequenos comandos que eles sabem exatamente onde armazenar sua informação ou buscar uma informação que você precise. all(), find(), fill(), save(), delete(). Estes caras são demais mas lembre-se: eles não trocam idéia com os controllers.

 

4. app//. Quem é esse cara?! ¬¬ Trata-se da sede da empresa, sendo aqui a empresa == sua app. Todas as minhas apps possuem um codinome e alguns exemplos são app/CBG/ app/ved/ app/whatever. O que se coloca nesta pasta? Tudo o que for específico da minha aplicação. Um bom exemplo é repositório: como eles não estendem nada do framework, eu os considero meu domínio e por isso mesmo os acondiciono na pasta app//Repositories. O mesmo vale para Services e até mesmo meus models.

 

É importante lembrar que a pasta de domínio precisa ser mencionada no composer.json na propriedade PSR-4 e que após salvar o composer.json vc precisa no terminal rodar composer dump.

 

5. app/Vedovelli/Repositories/ – os repositórios são os melhores amigos dos models e seu papel na app é dos mais importantes: eles guardam a inteligência da app! Só eles sabem como a informação deve ser formatada antes de ser devolvida à rota. Normalmente eles são colocados à disposição dos controllers (ou seja: fazem o meio de campo entre os arqui-inimigos controllers e models) e sabem tudo sobre determinada funcionalidade. Um bom exemplo é o ProductRepository.php, que quando recebe dados de produto sabe exatamente onde guarda-los ou então quando se pede uma lista de produtos formatada bonitinha para ser a fonte de dados de um

 

6. app/Vedovelli/Services/ – estes caras rodam o mundo, são destemidos. Sempre que eu preciso que minha aplicação se comunique com o mundo exterior, eu crio um novo service. Um bom exemplo é o app/Vedovelli/Services/MailService.php que usa a API do Mandrill para enviar todos os e-mails transacionais. Se um controller precisa mandar um e-mail, basta injetar o MailService.php e usar o método correspondente. O que? O método ainda não existe?! Crie no MailService.php e o novo método provavelmente poderá útil em mais de um lugar. Vai saber?!

 

7. app/Http/Requests/ – estes objetos carregam consigo toda a informação passada da rota para o controller. Pense num request com uma mala que contém não apenas a informação passada pelo usuário mas as instruções do que deve ser feito com esta informação. Por fim, uma requisição pode conter uma lista do que a mala contém e se a mala estiver com informação de menos, o FormRequest já faz cara feia e devolve a mala para a rota, que já vai informar ao usuário o que ele esqueceu de enviar.

 

Por conter regras específicas de sua app, os FormRequests precisam ser criados um a um, sempre que necessário. Isso é muito fácil por haver uma instrução no Artisan que faz isso!

 

8. resources/views/ – aqui fica a favela! Esta vizinhança é uma bagunça mas esconde grande beleza! As ruas podem até não ser retas e largas e não serem asfaltadas, mas aqui sobra alegria e companheirismo. Todos entram na casa dos demais sem a necessidade de serem convidados (includes) e se chamam de irmãos sem terem nascidos da mesma mãe (extends). No final das contas, essa gente batalhadora é quem dá a cara à sua aplicação, colocando sua cara bonita na informação carrancuda que a galera do almoxarifado manda. Mas que é uma zona, isso é fato!

 

9. app/Vedovelli/Presenters/ – essa galera ajuda o pessoal da favela a mostrar os dados de forma mais arrumada. Por exemplo. Se o pessoal do almoxarifado (que é muito ocupado) mandar nome e sobrenome mas se precisa do nome completo, o UserPresenter (que é o Model disfarçado para não ser reconhecido pelo Controller) é quem contém a lógica para concatenar nome e sobrenome para formar o nome completo. Algo como public function nomeCompleto(){ return $this->firstname .’ ‘. $this->lastname; }. Ele trabalha muito bem com datas, sabe?!

 

 


1

Share

Donate to Site


About Author

Renato

Developer

Add a Comment
Comments 0 Comments

No comments yet! Be the first to comment

Blog Search


Categories

OUTROS (15) Variados (109) PHP (130) Laravel (157) Black Hat (3) front-end (28) linux (111) postgresql (39) Docker (25) rest (5) soap (1) webservice (6) October (1) CMS (2) node (7) backend (13) ubuntu (54) devops (25) nodejs (5) npm (2) nvm (1) git (8) firefox (1) react (6) reactnative (5) collections (1) javascript (6) reactjs (7) yarn (0) adb (1) Solid (2) blade (3) models (1) controllers (0) log (0) html (2) hardware (3) aws (14) Transcribe (2) transcription (1) google (4) ibm (1) nuance (1) PHP Swoole (5) mysql (31) macox (4) flutter (1) symfony (1) cor (1) colors (2) homeOffice (2) jobs (3) imagick (2) ec2 (1) sw (1) websocket (1) markdown (1) ckeditor (1) tecnologia (14) faceapp (1) eloquent (14) query (4) sql (40) ddd (3) nginx (9) apache (4) certbot (1) lets-encrypt (3) debian (11) liquid (1) magento (2) ruby (1) LETSENCRYPT (1) Fibonacci (1) wine (1) transaction (1) pendrive (1) boot (1) usb (1) prf (1) policia (2) federal (1) lucena (1) mongodb (4) paypal (1) payment (1) zend (1) vim (4) ciencia (6) js (1) nosql (1) java (1) JasperReports (1) phpjasper (1) covid19 (1) saude (1) athena (1) cinnamon (1) phpunit (2) binaural (1) mysqli (3) database (42) windows (6) vala (1) json (2) oracle (1) mariadb (4) dev (12) webdev (24) s3 (4) storage (1) kitematic (1) gnome (2) web (2) intel (3) piada (1) cron (2) dba (18) lumen (1) ffmpeg (2) android (2) aplicativo (1) fedora (2) shell (4) bash (3) script (3) lider (1) htm (1) csv (1) dropbox (1) db (3) combustivel (2) haru (1) presenter (1) gasolina (1) MeioAmbiente (1) Grunt (1) biologia (1) programming (22) performance (3) brain (1) smartphones (1) telefonia (1) privacidade (1) opensource (3) microg (1) iode (1) ssh (3) zsh (2) terminal (3) dracula (1) spaceship (1) mac (2) idiomas (1) laptop (2) developer (37) api (4) data (1) matematica (1) seguranca (2) 100DaysOfCode (9) hotfix (1) documentation (1) laravelphp (10) RabbitMQ (1) Elasticsearch (1) redis (2) Raspberry (4) Padrao de design (4) JQuery (1) angularjs (4) Dicas (37) Kubernetes (2) vscode (2) backup (1) angular (3) servers (2) pipelines (1) AppSec (1) DevSecOps (4) rust (1) RustLang (1) Mozilla (1) algoritimo (1) sqlite (1) Passport (1) jwt (4) security (2) translate (1) kube (1) iot (1) politica (2) bolsonaro (1) flow (1) podcast (1) Brasil (1) containers (2) traefik (1) networking (1) host (1) POO (2) microservices (2) bug (1) cqrs (1) arquitetura (2) Architecture (3) sail (3) militar (1) artigo (1) economia (1) forcas armadas (1) ffaa (1) autenticacao (1) autorizacao (2) authentication (4) authorization (2) NoCookies (1) wsl (4) memcached (1) macos (2) unix (2) kali-linux (1) linux-tools (5) apple (1) noticias (2) composer (1) rancher (1) k8s (1) escopos (1) orm (1) jenkins (4) github (5) gitlab (3) queue (1) Passwordless (1) sonarqube (1) phpswoole (1) laraveloctane (1) Swoole (1) Swoole (1) octane (1) Structurizr (1) Diagramas (1) c4 (1) c4-models (1) compactar (1) compression (1) messaging (1) restfull (1) eventdrive (1) services (1) http (1) Monolith (1) microservice (1) historia (1) educacao (1) cavalotroia (1) OOD (0) odd (1) chatgpt (1) openai (3) vicuna (1) llama (1) gpt (1) transformers (1) pytorch (1) tensorflow (1) akitando (1) ia (1) nvidia (1) agi (1) guard (1) multiple_authen (2) rpi (1) auth (1) auth (1) livros (2) ElonMusk (2) Oh My Zsh (1) Manjaro (1) BigLinux (2) ArchLinux (1) Migration (1) Error (1) Monitor (1) Filament (1) LaravelFilament (1) replication (1) phpfpm (1) cache (1) vpn (1) l2tp (1) zorin-os (1) optimization (1) scheduling (1) monitoring (2) linkedin (1) community (1) inteligencia-artificial (2) wsl2 (1) maps (1) API_KEY_GOOGLE_MAPS (1) repmgr (1) altadisponibilidade (1) banco (1) modelagemdedados (1) inteligenciadedados (4) governancadedados (1) bancodedados (2) Observability (1) picpay (1) ecommerce (1)

New Articles



Get Latest Updates by Email