PHP e MVC – Tudo o que você precisa saber

Descubra

O que é MVC? Qual a responsabilidade de cada camada? Porque ele não é suficiente para se desenvolver a maioria dos projetos PHP? Ele vai morrer? Espero responder de uma vez por todas estas perguntas, esclarecer os fatos e deixar minha opinião sobre o padrão de arquitetura.

Orgulho deste ser meu primeiro artigo “de verdade” no novo blog.

Antes de qualquer coisa, não da pra falar de PHP e MVC sem nivelarmos os conhecimentos, então sinta-se livre para pular o próximo tópico se você está seguro de seus conhecimentos, mas se existe alguma chance de dúvida, leia! Não custa nada.

Este é o primeiro artigo de uma série sobre organização de projetos PHP, se você quiser ser avisado sobre os próximos, assine a newsletter.

O que é MVC?

https://pt.wikipedia.org/wiki/MVC – Para ajudar, MVC na Wikipedia.

MVC é um padrão de arquitetura, a proposta dos architectural patterns (padrão de arquitetura em inglês) é fornecer soluções para problemas conhecidos durante a etapa de arquitetura do software, em outras palavras, eles fornecem um padrão de trabalho que ajudam na hora de organizar (o termo correto seria arquitetar) seu projeto.

A proposta do MVC é separar a camada lógica da camada de visualização, isso vai evitar que você tenha sua aplicação mais bem definida e evitando (dentre outras possibilidade) que você escreva SQL no meio do HTML, por exemplo.

MVC e PHP se tornou uma stack muito poderosa e que é o princípio para ter uma aplicação organizada, mas NUNCA deve abranger a totalidade do projeto, outras camadas podem existir em harmonia.

Mas o que é, de fato, MVC?

MVC é o acrônimo de Model, View e Controller e cada uma destas camadas tem uma responsabilidade, aqui vou evitar falar da proposta original, que difere um pouco da proposta web (tem um link da Wikipedia acima, use para saber mais).

Model se refere a camada lógica, no nosso caso, tudo o que é relativo aos dados, na maioria das implementações quer dizer banco de dados, aqui fazemos consultas ao banco (leitura, escrita e remoção), validações (embora algumas propostas separem essa camada, o que não quer dizer que está errado), construções de regras de negócio relacionadas a manipulação dos dados.

View gerencia a camada de exibição e isso não quer dizer que não possa ter lógica aqui, quero dizer, você ainda pode usar if e else, loops e tudo o que quiser, desde que o foco seja a renderização da exibição, quer seja um HTML para o usuário ou um JSON ou XML para uma api.

Controller é o cara que dita o fluxo, ele que diz quando o model deve fazer alguma coisa, quais dados serão passados para o model e quando e como a camada de view precisa renderizar alguma exibição, por conta disso, na nossa realidade de desenvolvimento WEB, o controller tem acesso as informações de request e response para fazer seu trabalho. Novamente, usar ifs, elses e loops não quer dizer que o controller está errado, desde que o foco seja ditar o fluxo do processo. Num geral, ele deve ser pequeno e simples, mas toda classe deve ser assim, não só os controllers.

Existem várias regrinhas que se espalharam como um câncer pela web e não são necessariamente verdade (também não são totalmente mentira), como por exemplo:

  • Não podemos ter estruturas de controle (if e switch, por exemplo) nas views e controllers, isso porque existe uma confusão com lógica de programação e lógica de negócio, são coisas diferentes!
  • O controller precisa ser menor que o model. Isso não tem nada haver, existem abstrações (como o Eloquent faz) onde é possível criar uma classe de model sem um único método ou atributo, como você faz um controller menor que isso?
  • Validação deve ficar em uma camada separada. Existem possibilidades e diferentes tipos de visões, não quer dizer que uma proposta é melhor ou a única verdadeira, pensar que você achou a ferramenta definitiva é que é ruim, saiba usar para saber escolher.

Resumindo

  • Model: Responsável pelos dados
  • View: Responsável pela camada de renderização
  • Controller: Responsável pela ordem de execução

Qualquer coisa além disso deve ser encarado, no máximo, como um reforço ao padrão e nunca como regra absoluta, se reserve no direito de ser inteligente o suficiente para quebrar regras em prol de um aplicativo melhor.

MVC é o suficiente no desenvolvimento web com PHP?

Não! Mas é claro que não, e aqui começam os problemas.

Aonde você faz disparos de email? Aonde você faz o envio de uma publicação que deverá ser postada automaticamente no Facebook? Aonde você dispara dados para o Socket.io para ter um app real-time? Aonde você verifica as permissões do usuário? Aonde você verifica se o usuário já aceitou as novas politícas do site antes de renderizar uma página?

Tudo isso são incognitas que fizeram surgir teorias como as que ditam que o MVC vai morrer quando a verdade é que nada disso é problema dele, o MVC não vai resolver tudo pra você, ele é a porta de entrada, só isso, lembre-se de seguir o princípio da responsabilidade única:

Cada classe deve ter um único motivo para sua existência

— Single Responsability Principle – SOLID

Com isso em mente, por favor, NUNCA bagunce seu MVC com o que não lhe compete, mas vou falar disso no próximo tópico.

PHP além do MVC

Não posso dizer que minha forma de trabalhar é a melhor do mundo, mas funciona muito bem pra mim, quem sabe ajude você.

Além do MVC eu gosto de trabalhar com:

  • Middlewares
  • Events e Listeners
  • Modularização

Cada uma destas camadas são responsáveis por alguma coisa, claro que cada um deles é assunto para outro dia, mas vou deixar um pequeno resumo aqui.

Middlewares são responsáveis por interceptar as requisições e empilhar processos, a própria rota (que define, na maioria das vezes, qual controller será usado) é um middleware por definição.

É no middleware que eu, normalmente, dito o que deverá acontecer antes ou depois do controller ser executado, por exemplo, se o usuário não está autenticado eu devo parar a execução no middleware ANTES dele chegar no controller ou até posso gerar um log sobre o que aconteceu durante a exeução da aplicação após a execução do MVC.

Events e listeners são um show a parte, de longe a camada mais importante depois do MVC, normalmente os eventos são disparados de dentro do MVC e em cada um eu posso anexar ou desanexar QUANTOS listeners eu quiser e estes listeners são classes isoladas que fazem qualquer coisa, como enviar emails, consultar APIS (lembra da postagem no Facebook que eu disse acima, faria aqui), fazer pagamentos de cartão.

Com um bom sistema de events e listeners eu poderia até jogar as tarefas numa fila em background e o usuário nem precisa esperar isso acontecer, em outras palavras, aplicações mais organizadas e performáticas.

Modularização é onde eu agrupo responsabilidades específicas para poder reaproveitar, um sistema de autenticação com lembrar de mim, login social, oauth2 e crud de usuários com relatórios seria um módulo pronto e separado, facil de instalar (poucos passos) e de mantém (manutenção centralizada com versionamento semântico).

Conclusão

MVC é um padrão de arquitetura que vai te ajudar a organizar suas aplicações, mas não quer dizer que ele englobe todos os processos do app, você precisa saber que outras camadas serão bem vindas.

Este é o primeiro artigo de uma série sobre organização de projetos PHP, se você quiser ser avisado sobre os próximos, assine a newsletter.

4 comentários em “PHP e MVC – Tudo o que você precisa saber”

  1. Fala Erik! Parabéns pelo post, sempre muito bem explicado e rico em detalhes. Quero agradecer primeiramente suas aulas na SON, pois só com elas eu pude aprender PHP de verdade, num passo-a-passo onde tudo faz sentido. Espero consumir muito conteúdo sobre essa linguagem que tenho muito carinho, e com certeza é o meu ganha pão hoje. Seu cursos da SON me ajudaram a conseguir meu primeiro em prego na área, onde estou até hoje trabalhando como dev, isso que na época eu tinha acabado de ficar desempregado, peguei uma grana assinei e fiz seus cursos de PHP “como se não houve amanha” hahahahaha e hoje minha família desfruta das minhas conquistas. Então mais uma vez muito obrigado de coração.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *