MVC na prática - Entendendo o padrão MVC na prática Artigo

Conheça os cursos gratuitos do WebDevBr! - Inscreva-se!


Este artigo foi publicado a 1 ano, 9 meses, 5 dias atrás.

MVC é o design pattern que separa a "camada lógica" da "camada de exibição" em uma aplicação e é largamente utilizado desde projetos pequenos até os realmente muito grandes, veja por exemplos os frameworks PHP, Zend Framework, Laravel, CakePHP e muitos outros usam e abusam do MVC.

Nesta aula quero montar um exemplo de código utilizando MVC sem usar qualquer ferramenta externa, vou tentar me manter o mais simples possível, mas vamos entender como vai funcionar a coisa.

Eu vou ter 3 arquivos separados que vão guardar todo o nosso código, mas ai você se pergunta, 3 três camadas, Erik? Sim!!!

Gostou deste artigo?

Receba atualizações semanais com novos artigos do WebDevBr e outras dicas!

A primeira camada vai guardar toda a lógica, ou seja, conexão ao banco, selects, inserts... A terceira vai exibir estes dados. E a do meio, a segunda, vai dizer quando chamar as outras camadas (a primeira e a terceira) e o que elas devem fazer, um mapa por assim dizer.

Vamos dar nomes a estas camadas.

Os outros artigos desta série.

As camadas do MVC

MVC é o acrônimo de Model, View e Controller:

Model é onde fica a parte lógica da aplicação, ou seja, todos os recursos da sua aplicação (consultas ao banco de dados, validações, lógica de disparo de email...), mas ele não sabe quando isso deve ser feito, a camada de model apenas tem o necessário para que tudo aconteça, mas não executa nada de fato. Na verdade o MVC é "mais aplicado" com requisição e tratamento de dados relacionados ao banco, o que acontece é que temos um código mais elaborado surgem muito mais camadas, por exemplo, note que eu inclui a "lógica de disparo de email", mas na verdade isso acaba sendo feito em outras partes da aplicação, por exemplo, no CakePHP temos o Mailer, que é uma camada totalmente independente para se trabalhar com emails, para o Zend Framework tem um pacote para isso e o Laravel usa o SwiftMailer através do recurso Mail, nenhum deles está explicito na camada Model, embora seja o lugar mais obvio (se alguém me forçar a categorizar).

View é onde fica todo o necessário para exibir dados, e isso pode ser muito amplo, imagine um componente para renderizar formulários ou tags HTML, ou mesmo um menu multinível, toda essa lógica fica na view, assim como a Model, a View não sabe quando deve ser executada, ela apenas sabe como fazer, não quando.

Controller é onde tudo acontece realmente, ele é o cara que não sabe como fazer, mas sabe quando. Muitos dizem que o controller não deve ter regras de negócio e automaticamente já entendem que não se deve ter estruturas de controle (if, else...), na verdade é obrigação do controller dizer o que deve acontecer e quando, então imagine que você tem uma página com formulário, como você faria para identificar se a requisição foi pelo formulário o não? Então, o controller deve saber quando fazer as coisas e você deve implementar o necessário para que isso se torne realidade.

Outra camada que (na minha opinião) faz parte do controller é o router, ou roteamento, ela é quem pega a URL digitada e identifica qual controller deve ser chamado, o controller por sua vez executa o model e o view respectivos.

Exemplo prático de MVC

Mas vamos ver um exemplo prático, um "hello world" em MVC. Crie um arquivo chamado index.php com o seguinte conteúdo:

<?php

//executo o controller
include 'controller.php';
(new Controller)->action();

Note que eu coloquei o controller dentro de parenteses, isso faz com que não seja necessário eu instanciar em uma variável, já que só vou usar isso agora, então eu executei um método chamado action(), o action é uma "parte" do controller, normalmente usamos para definir uma página expecifica, por exemplo, um controller chamado Usuarios poderia ter actions login, logout, editar, ver, apagar...

Agora vamos criar nosso arquivo controller.php, ele deve se parecer com isso:

<?php

include 'model.php';
include 'view.php';

class Controller
{
        public function action()
        {
                $message = (new Model())->getMessage();
                return (new View($message))->render();
        }
}

É normal nosso controller acabar menor que as outras camadas, mas isso não é uma regra a se seguir, parem de dizer isso, por favor!

Nosso Model:

<?php

class Model
{
    public function getMessage()
    {
        //Aqui eu crio minhas regras,
        //por exemplo, buscar esta mensagem
        //no banco de dados
        return 'Hello World';
    }
}

Nosso View:

<?php

class View
{
        private $message;

        public function __construct($message) {
                $this->message = $message;
        }

        public function render()
        {
                echo $this->message;
        }
}

Claro que para um exemplo de impressão de um texto estático é meio que desnecessário isso, mas imagine as possibilidades, além de separar suas regras de negócio do HTML (na maioria dos casos é HTML, mas a view está relacionada a retornar dados de muitas outras formas, como servidores rest, por exemplo), você pode trocar o tipo do banco de dados, ou até incrementar muito mais a sua camada de model com tratamentos, validações, busca a banco de dados, alerta por email ou sms sempre que alguém exibir a mensagem, enfim... e o controller e a view ficariam intactos (embora eu prefira deixar as coisas mais explicitas). MVC é ideal para qualquer projeto maior que este exemplo.

Nos próximo artigos tudo vai ficar muito mais claro e objetivo a medida que implementarmos um projeto real (embora simples), com consulta ao banco de dados, uma camada de view mais elaborada e o Slim Framework para o controller.


Cursos relacionados


* Parcelamento apenas cartão de crédito! Pode haver uma pequena variação no parcelamento em relação a simulações apresentadas!