Explicando a arquitetura MVC

Entenda como funciona a arquitetura MVC, e dê uma turbinada no seu projeto em questão de perfomance, organização e etc.

Como funcionam as aplicações web?

Padrões de desenvolvimento

Hoje em dia tudo que roda em nossos computadores, desde o navegador, o word que nós editamos documento de texto, até a calculadora do computador que utilizamos para fazer contas, foram necessários um planejamento para o desenvolvimento dessa aplicação, seja ela Desktop, Mobile ou Web.

Sabemos que hoje em dia a construção de um software pode ocorrer de várias formas, para isso temos a engenharia de software que consegue estruturar desde o início de um projeto a arquitetura da aplicação, dando as coordenadas iniciais que uma equipe deve seguir, até o momento da sua finalização. Hoje em dia na tecnologia, tudo existe um padrão, e para a construção de aplicações web também não é diferente.

A maioria dos softwares hoje em dia são (construídos) de forma incremental, o que significa ser feito por partes, componentes, micro-serviços, e geralmente utilizando metodologias ágeis como Scrum e Kanbam. Mas o fato é, assim como a estruturação de um projeto a aplicação web também mantém um modelo de arquitetura que visa facilitar a vida dos programadores, em problemas que já são recorrentes em projetos.

Modelos de arquitetura e Design Patterns são modos que os próprios desenvolvedores arrumaram para poder solucionar problemas de forma eficiente, que aparecem com frequência em qualquer categoria de projeto. Assim sabendo os problemas mais comuns foram desenvolvidos padrões de desenvolvimento, para acelerar a entrega de um software e deixar um código mais limpo, um exemplo de Design Pattern bastante utilizado é o MVC(Model, View e Controller).

Para entender como funcionam as aplicações web, é indispensável entender como é a lógica, e as camadas por quais os dados trafegam por debaixo dos panos. E nada melhor do que entender como funciona isso, utilizando um padrão de desenvolvimento utilizado na maioria dos frameworks de desenvolvimento atualmente, o MVC.

Frameworks que utilizam MVC:

• Laravel(PHP)
• CodeIgniter(PHP)
• Spring MVC(Java)
• Django(Python)
• Ruby on Rails(Ruby)

MVC - Visão Geral

MVC é um padrão de desenvolvimento ou um modelo de arquitetura? Muitas pessoas acabam sempre caindo nessa discussão, mas nesta postagem ele será tratado como um padrão de desenvolvimento já que é um padrão que trabalha na organização do seu projeto em alto nível.

Fonte: Wikipédia

O MVC é um padrão de projeto de software ou padrão de arquitetura de software formulado na década de 1970 por Trygve Reenskaug para um mini sistema que ele desenvolveu, focado no reuso de código e a separação de conceitos em três camadas interconectadas.

Mesmo tendo sido desenvolvida inicialmente para computação pessoal, o MVC foi drasticamente adaptado como uma arquitetura para as aplicações web em todas as maiores linguagens de programação visando ter uma melhor resposta nas transições entre as camadas de dados.

Fonte: Wikipédia

Em resumo as camadas conversam entre si, de forma separada, para melhor organização e eficiência na transação de dados. De forma bem resumida o usuário solicita alguma informação na View, na qual o navegador irá bater em uma rota, que é a responsável por organizar os Controllers, a rota solicita ao Controller esses dados, que solicita ao Model pois sabe que esses dados estão armazenados em um banco de dados, assim o Model adquiri esses dados e retorna os mesmos para o Controller, fazendo o caminho inverso.

Um pouco confuso né, mas não se preocupe, nós vamos passar de forma mais explicada por esses termos para ficar mais claro.

View <-> Rotas <-> Controller <-> Model <-> Banco de Dados

Model

Model ou camada de modelação, é a principal camada que tem como objetivo fazer a conexão com o banco de dados e trazer esses dados de forma organizada.
Essa camada é a principal na função de adquirir os dados do banco de dados e modelar adequando os dados de acordo com a linguagem.
Se efetuarmos uma consulta em um banco de dados, ele irá nos retornar uma quantidade de dados na linguagem do banco de dados.

Exemplo:

Isso está retornando dados, porém ele ainda não está modelável, pois ainda está em linguagem de Manipulação de Dados, ou melhor falando em SQL(Structured Query Language, e não é possível exibir os dados dessa maneira para o usuário lá no navegador, pois nem a linguagem utilizada no MVC, nem o navegador será capaz de interpretar.

Em outra postagem será explicado um pouco mais sobre banco de dados e a linguagem SQL utilizada, assim como a diferença entre linguagens compiladas e interpretadas.

Sendo assim, quando efetuamos uma consulta no banco de dados é necessário traduzir essa estrutura de dados, para que a nossa linguagem utilizada no MVC seja capaz de interpretar assim como o navegador.

Uma transação simboliza uma unidade de trabalho executada dentro de um sistema de gerenciamento de banco de dados. É importante conhecer esse termo, pois em conjunções com linguagens de programação, para melhor performance é necessário entender o conceito de transação.

Voltando ao assunto de traduzir essa estrutura de dados para algo que nossa linguagem possa interpretar, vamos mostrar abaixo um código que faz essa consulta e tradução desses dados.

public function PegarPorId($id) {
$query = $this->db->prepare("SELECT nome, 
idade, 
profissao, 
aniversario 
FROM pessoas 
WHERE id = ?");

$query->bind_param('i', $id);
$query->execute();
$query->bind_result($nome, $idade, $profissao, $aniversario);
return GeraListaId($query);
}
public function GeraListaId($query){
$lista = array();
$i = 0;
while($query->fetch()){
$lista[$i]['nome'] = $nome;
$lista[$i]['idade'] = $idade;
$lista[$i]['profissao'] = $profissao;            
$lista[$i]['aniversario'] = $aniversario;
$i++;
}
return $lista;
}

Onde os métodos acima são comumente utilizados em camadas de modelagem(Model) para poder adquirir um dado do banco de dados e traduzir para a linguagem, nesse caso PHP.

O metódo PegarPorID é o responsável por solicitar uma transação para o banco de dados com as informações de nome, idade, profissão e aniversário a partir de um ID, na qual é utilizado para buscar por alguma informação especifica. Após solicitar a informação, é retornado o método GeraListaId.

Já o método GeraListaId é o responsável para fazer essa tradução dos dados para adequar a linguagem e ser mais fácil de lidar com os dados que foram retornados da transação do banco de dados.

É rodado uma estrutura de repetição para poder juntar as linhas retornadas e inserir em um array, que resumidamente é uma estrutura de dados que armazena um conjunto de dados em segmento, na qual fica mais fácil para poder localizar algum dado.

Basicamente, é mais fácil lidar com um array do que com um dado “cru” que é retornado por uma transação. A facilidade do array é que ele nos retorna um índice de onde um dado pode estar.

Fonte: GeekforGeeks

Então acima, vemos um array, na qual se pegarmos o valor do índice 0, o código irá nos retornar o valor 7, e assim por diante. É mais fácil localizar um dado quando se tem um índice.

Para tornar o conceito mais simples, podemos imaginar um armário com várias gavetas, vamos a identificar como gaveta 0, gaveta 1, gaveta 2 e assim por diante para ficar mais fácil de achar roupas depois.

Então se eu guardo uma blusa na gaveta 0, uma calça na gaveta 1, e um boné na gaveta 2, fica mais fácil de identificar onde está cada coisa. Então me diga, em qual gaveta está o boné?

E agora, olhando para a imagem de um array, em qual posição está o número 9?

Fonte: GeekforGeeks

Controller

E é aqui que acontece toda mágica por trás de uma aplicação. Geralmente o controller é o responsável por fazer as conexões entre View e Model e tratar os dados antes de enviar para o navegador para que o usuário possa visualizar.

O controller é responsável pelas regras de negócio de um sistema, então quando é solicitado uma informação como “Quanto é 1 + 1?”, o Controller é responsável para achar essa informação. Ou algo do tipo “O usuário fulano tem acesso a essa página?”, o controller será o responsável por buscar essa informação e retornar para a View para o usuário.

Um exemplo de código PHP utilizando o framework Laravel, é o abaixo onde recebe a solicitação de achar informações sobre uma determinada lixeira, na qual procura pelo identificador.

function find(Request $request){
$id = $request->input('id_organization');
$TrashOrganization = new TrashOrganizationModel;
$organization_info = $TrashOrganization->find($id);
return json_encode($organization_info);
}

A função find recebe um parâmetro chamado Request, que são os dados que são passados da View para o controller em uma requisição.

A variável “id” recebe da requisição feita pela View, a chave “id_organization”. Em resumo, muito das aplicações webs utilizam diversas formas de conversar entre o navegador e o servidor, o que implica na forma de enviar os dados.

Voltando ao assunto do método find, na próxima linha é chamado a classe TrashOrganizationModel, na qual é aonde se encontra o model que fará a conexão com o banco de dados e realizará a transação necessária para buscar os dados. Nessa linha estamos falando para nosso código, “Olha, existe essa classe TrashOrganizationModel, lembra dela (ai), que depois eu vou usar.”.

E nas últimas linhas são as responsáveis por fazerem a solicitação para o model para achar uma informação a respeito de uma região específica. Então em resumo, nós recebemos uma requisição da View, que veio em uma requisição HTTP com chave e valor, nós chamamos a classe TrashOrganizationModel, e a partir dela chamamos um método para poder buscar esses dados no banco de dados e realizar a adequação a linguagem de programação.

View

A view é literalmente o que nós vemos em uma aplicação web, ela é responsável por solicitar as informações para o controller, e renderizar isso para o usuário.

A view a grande responsável pelos sistemas de hoje em dia serem melhores elaborados. Para se ter uma idéia os programas de antigamente, eram analógicos, então sem nenhuma interface, tendo apenas a informação necessária na tela, mas dá para compreender, na época que eram programas analógicos sem interface, a computação ainda caminhava seus primeiros passos para melhorar o hardware.

Com o melhoramento dos hardwares foi possível melhorar a interface e tornar de analógico para programas digitais e melhorar a interface, para ser algo mais agradável. Com isso nos anos 2000, quando as paginas HTML e CSS estavam ganhando espaço, muita gente investiu seu tempo para aprender a deixar suas páginas um pouco mais agradável para os usuários.

Contudo, nos anos 2000 tínhamos um grande problema, as páginas eram renderizadas pelo servidor e enviadas para o navegador. Isso é um problema computacional, já que se hospedarmos esse site em uma máquina não tão potente, era capaz de nosso site ficar fora do ar, pois o servidor não conseguiu processar toda essa renderização.

O servidor antigamente processava por página aberta e não conseguia reconhecer uma conexão. Então se um usuário abrisse 2 páginas, ele não reconhecia como apenas um usuário e alocava 2 espaços totalmente diferentes na memória para processar essa solicitação, sendo que poderia ser utilizado para um usuário autentico.

Agora imagine, seu site ter 10 usuários ativos no momento, e cada um abre pelo menos 3 páginas, no final o servidor tinha que processar pelo menos 30 páginas e dependendo das configurações do servidor ele poderia simplesmente cair, e isso foi um grande problema para época, e qual foi a solução? Por que não jogamos essa renderização para o navegador, e foi aí que surgiu conversas famosas como SOAP, REST e GraphQL, visando diminuir o trabalho do servidor de processar e renderizar as informações.

Atualmente a maioria dos sites força o usuário a renderizar todo o conteúdo mais pesado no navegador, e fazer solicitações de informação ao servidor, e essa conversa acontece com protocolo HTTP. Um dos verbos mais conhecidos são POST, GET e PUT para obtenção, alteração e inserção de dados.

POST - Envio de dados
GET - Obtenção de dados
PUT - Alteração de Dados

Um exemplo de View pode ser vista a baixo, na qual podemos ver o exemplo de um código HTML na, qual renderiza para o usuário no navegador, campos para informar algum tipo de dado. É possível enviar esses dados pelo próprio HTML também com a tag:

<form action="/action.php" method="POST">
<label for="fname">Nome:</label>
<input type="text" id="fname" name="fname"><br><br>
<input type="submit" value="Submit">
</form>

Renderizando um campo de Nome para o usuário e um botão para enviar esse dado. Ao clicar no botão, ele irá enviar essa informação ao arquivo action.php que é um controller que será responsável por tratar essa informação, tudo isso utilizando a requisição POST para enviar os dados.

O método anterior apesar de ser bastante utilizado está caindo em desuso, a forma mais atual de pegar esses dados do usuário e informar para o controller é utilizado com HTML+JS, outra linguagem de programação que interpretada no navegador, facilitando e melhorando o desempenho do site.

<label for="fname">Nome:</label>
<input type="text" id="fname" name="fname"><br><br>
<input type="submit" value="Submit" onclick=”EnviarDados()”>

<script>
function EnviarDados(){
var nome = document.querySelector(“#fname”).value

var body = {
method : 'POST',
headers: {
"Accept": "application/json",
"Content-Type": "application/json"
},
body: JSON.stringify({"id_organization": id})      
}

fetch(url,myinit)
.then(function(response){
response.json().then(function(dado){
console.log(dado)
})
})

}

</script>

Em resumo, tiramos a tag form- tags são quando se abre “<” e fecha “>” e a primeira palavra que vem é a nome da tag - pois ela não é mais necessária para nós. Em vez disso podemos utilizar o javascript para realizar essa ação sem ter a necessidade de atualizar a página. Temos a função EnviarDados() que não recebe nenhum parametro e é chamada assim que nós clicamos no botão de submit do html.

Assim que clicamos, ele executa a primeira linha de código, na qual vai pegar o valor do campo de nome do usuário. Ele pega esse valor, na váriavel body, ele monta o corpo da requisição para que o servidor consiga interpretar essa requisição e extrair os dados de forma correta, passando chave e valor traduzindo para JSON.

E depois temos a função fetch que funciona em promises, uma forma mais atualizada de lidar com dados no Javascript, que vai fazer essa requisição para o controller, e esperar a resposta e mostrar isso no console do navegador.

Rotas

No MVC, a Rota define um padrão para a URL a ser usada, e fixa como ela será tratada pelo Sistema.

Em resumo ela procura organizar as requisições para qual controller deve ir. Se quisermos acessar a pagina site.com, quais dados essa página deve retornar, ou qual controller ela deve chamar?

Bem, esse é um problema para rota definir, geralmente na estrutura MVC, nós temos um arquivo que armazena todas as rotas parecido com o abaixo, que está na linguagem PHP:

Route::post('/trash/create', [TrashController::class, 'create']);  
Route::put('/trash/update', [TrashController::class, 'update']);  
Route::put('/trash/update/capacity', [TrashController::class, 'updateCapacity']);  
Route::delete('/trash/delete', [TrashController::class, 'delete']);

Onde chamamos Route::VerboHTTP(‘url’,[Controller a ser chamado, Método do Controller chamado].

Então em um arquivo de rotas identificamos qual url está sendo chamada, e qual controller especificoele vai ser redirecionado para adquirir o dado.

O conceito de rotas é algo mais profundo no assunto de MVC, e deve ser pesquisado de acordo com a linguagem, pois isso pode alterar a forma de utilizar.

Conclusão

Agora que entendemos o conceito de Model, View e Controller, ficou mais fácil para podermos avançar em outras teorias como até uma programação orientada a objetos, se você estiver buscando desempenho no seu código, esse é o conceito correto. Em resumo sabemos que utilizar o padrão MVC, te poupará de sofrer muitas dores de cabeça, pois facilita e divide o código de acordo com seus fins e isso no final te dará uma melhor organização. As aplicações web em sua maioria são desenvolvidas nesse método, e uma ou outra são estruturadas de outra forma.

Há outras categorias de MVC que foram adaptados para os problemas do dia a dia do programador. Como dizemos na história design patterns e modelos de arquitetura foram feitos para facilitar a vida dos programadores em problemas do dia a dia.

E ai, no seu próximo projeto, web, que tal tentar utilizar essa estrutura, e depois conte para nós o que você achou!

Se você quiser se basear em um projeto que segue essa estrutura só clicar nos links abaixo, com as referências.

Repositório: https://github.com/phjb/app-mvc

**Referências: **

https://tableless.com.br/mvc-afinal-e-o-que/
https://pt.wikipedia.org/wiki/MVC
http://unifafibe.com.br/revistasonline/arquivos/revistaepeqfafibe/sumario/20/16112011142249.pdf
https://folk.universitetetioslo.no/trygver/themes/mvc/mvc-index.html
https://www.freecodecamp.org/news/what-exactly-is-client-side-rendering-and-hows-it-different-from-server-side-rendering-bd5c786b340d/
Leff and J. T. Rayfield, “Web-application development using the Model/View/Controller design pattern,” Proceedings Fifth IEEE International Enterprise Distributed Object Computing Conference, Seattle, WA, USA, 2001, pp. 118-127, doi: 10.1109/EDOC.2001.950428.