Posted on: August 29, 2019 08:16 AM
Posted by: Renato
Views: 557
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?!
Donate to Site
Renato
Developer