Olá, estudante! O objetivo da aula de hoje é entender uma parte da arquitetura de software utilizada em desenvolvimento para Web, que é também conhecida como Modelo Cliente–Servidor, em que temos dois agentes principais que, como você deve imaginar, são o cliente e o próprio servidor. O cliente — que, nesse caso, é o navegador Web — é quem solicita um determinado serviço por meio do envio de requisições ao servidor; e o servidor, por sua vez, é quem oferece os serviços aos seus clientes, ou seja, é onde são processadas as tarefas solicitadas, e, na sequência, devolve uma resposta ao cliente.

Acompanhado dessas informações, também apresentarei, nessa lição, como funciona o padrão MVC (Model, View e Controller) — Modelo, Visão e Controlador, em português —, que é uma arquitetura em que a interface gráfica é formada por objetos da camada de visão e por controladores, que são as classes que tratam e interpretam os eventos gerados por requisições da camada de visão, e as respostas são retornadas pela camada de modelo, que, por sua vez, são classes que armazenam os dados pela aplicação e que têm a ver com o domínio do sistema.

O Front-End se enquadra nesses dois assuntos, atualmente, como cliente no Modelo Cliente–Servidor e, na questão MVC, como já foi dito, nas camadas de visão e de controle. Pronto(a) para entrar nesse mundo de modelos e arquiteturas?

O Padrão MVC (Model, View, Controller) surgiu para solucionar um problema comum em aplicações de software: a falta de separação clara entre as diferentes camadas de responsabilidades do sistema. Com a implementação desse padrão, é possível separar a lógica do negócio (Model), a apresentação dos dados (View) e a interação do usuário (Controller), tornando o desenvolvimento e, principalmente, a manutenção do código mais organizados e eficientes.

Esse problema tem maior escala em aplicações Web e facilita a criação de interfaces de usuário mais amigáveis e responsivas, pois a lógica de interação do usuário é separada do código de negócio, o que dá liberdade à pessoa desenvolvedora Front-End de não ter que se preocupar com códigos de negócios em meio ao design da aplicação.

Se o Model representa a camada de dados do sistema e contém a lógica de negócio, no Front-End, trabalha-se, efetivamente, na camada de View, que é a responsável por apresentar os dados do Model para o usuário e pode incluir recursos como HTML, CSS e JavaScript, enquanto o Controller é o intermediário entre o Model e a View.

Com a solução do padrão MVC, você torna o código mais modular e escalável, facilitando a manutenção e o desenvolvimento de novas funcionalidades.

O case fictício apresentado hoje será sobre a empresa Best Practices Software Inc., que foi contratada para desenvolver um sistema Web de vendas para um cliente. Esse novo projeto é necessário porque o software que a empresa possui atualmente tem se tornado muito difícil de manter e escalar, pois a lógica de negócio, a apresentação de dados e a interação do usuário estavam muito misturadas no código e eram necessárias muitas horas de trabalho para uma simples alteração em seu código.

A equipe responsável pelo projeto começou o desenvolvimento desse novo software, e um dos requisitos não funcionais era a utilização do Padrão MVC na criação desse novo sistema. A equipe iniciou criando a camada Model, que é a responsável por gerenciar os dados de vendas, como os pedidos, produtos, estoques e pagamentos, inclusive, podendo se conectar com o banco de dados já existente na empresa.

Na sequência, foi desenvolvida a camada View, a qual é responsável por apresentar os dados do Model para o usuário. Com o uso de HTML, CSS e JavaScript, foi criada uma interface de usuário intuitiva e responsiva, na qual serão exibidas informações como o histórico de pedidos do usuário, os produtos disponíveis para venda, o carrinho de compras e o status do pagamento.

Finalizando o projeto, veio a criação do Controller, que é o responsável por intermediar a comunicação entre a View e o Model. Ele processa as requisições do usuário, como adicionar um produto ao carrinho, finalizar a compra ou cancelar um pedido e, também, manipula os dados do Model, como atualizar estoque ou alterar status do pedido.

Ao final do projeto, a equipe verificou que, com o uso do Padrão MVC, o código ficou mais organizado, modular e escalável, além da interface do usuário ter ficado mais intuitiva e responsiva, o que teve como resultado uma maior satisfação do usuário com o sistema.

Modelo Cliente–Servidor 

A maioria das vezes em que se trabalha com desenvolvimento Web, de sites e/ou aplicações, provavelmente, trabalhar-se-á em um ambiente com o Modelo Cliente–Servidor, isso porque o HTTP (Protocolo de Transferência de Hipertexto, em português) funciona por meio de requisições e resposta, o que traz as seguintes questões: quem faz as requisições? Quem devolve as respectivas respostas? A resposta para essas questões é simples: quem faz as requisições é um cliente, e ele faz essas questões para um servidor, que tem como responsabilidade servir a um ou mais clientes, assim, ele recebe a requisição e muito rapidamente tem a resposta, em seguida, devolve-a para o cliente que a solicitou.

Tanenbaum, Feamster e Wetherall (2021) dizem que o Modelo Cliente–Servidor é bastante usado e forma a base de grande parte do uso da rede. A realização mais popular é a de uma aplicação Web, em que o servidor fornece páginas Web com base em seu banco de dados em resposta às solicitações do cliente. Essa arquitetura permite que pessoas desenvolvedoras distribuam o processamento de informações entre o cliente e o servidor, o que pode resultar em uma experiência de usuário mais rápida e eficiente, como você verá em uma próxima lição sobre SPA (Single Page Applications, ou Aplicações de Página Única, em português).

Um ponto que você deve ter atenção é com relação ao servidor, pois, ao desenvolver, criamos um servidor pessoal em nossa máquina, a fim de simular esse ambiente de requisições e respostas. Com essa informação, pode ser que você tenha pensado na seguinte pergunta: será que minha máquina pode ser um servidor para todos os usuários de minha aplicação? Eu diria que depende, por questões de poder computacional, eu diria que sim, mas, pela questão de latência, eu diria que não. 

Portanto, o servidor de produção — ambiente que chamamos quando a aplicação está disponível para seus usuários — deve ter uma latência desejável de 24/7 (24 horas por dia, 7 dias por semana). As grandes empresas na área, normalmente, garantem em contrato algo acima de 99%, porque 100% não deveria existir, tendo em vista manutenções, atualizações etc.

Padrão MVC 

O Padrão MVC (Model-View-Controller), também chamado de Padrão Arquitetural, foi proposto, segundo Valente (2020), no final da década de 70 e, em seguida, usado na implementação de Smalltalk-80, que é considerada uma das primeiras linguagens orientadas a objetos. O Padrão MVC foi escolhido pelos projetistas de Smalltalk para implementação de interfaces gráficas e define que as classes de um sistema devem ser organizadas em três grupos: Visão, Controladoras e Modelo.

Visão (View) 

Dall'oglio (2018) define que uma classe de Visão representa a fronteira (interface) da aplicação com seu usuário e tem como principal responsabilidade a apresentação e obtenção de dados ao usuário. Uma classe de Visão também define, entre outras coisas, como os campos serão organizados em tela e, principalmente, define que ela não deve conter lógica de negócios.

Controladoras (Controller — controle) 

Essa categoria de classe é responsável por receber dados e ações do usuário, interpretá-las e solicitar quem execute as tarefas correspondentes. Segundo Dall'oglio (2018), um bom exemplo de utilização ocorre quando um Controller (Controladora) recebe da View (Visão) um conjunto de dados e uma ação requisitando a atualização desses dados na base. Então, de acordo com o Padrão, esse Controller aciona o Model (Modelo), que, por sua vez, faz a atualização e informa o Controller (Controladora) para ele acionar a View para apresentar os resultados ao usuário.

Modelo (Model) 

Classes de modelo representam as informações e regras do domínio de negócios da aplicação, ou seja, todos os “segredos” da aplicação estão e devem estar nessa camada. Dessa forma, classes que representam tabelas do banco de dados, classes que formatam dados, classes que transformam e transportam dados, todas elas devem ser organizadas e catalogadas como Model (Modelo) do sistema. Dall'oglio (2018) diz que uma classe Model (Modelo) tem como responsabilidades manter as informações de negócio e implementar métodos que representam as regras de negócio do domínio. 

A Figura 1, que você verá a seguir, representa uma espécie de fluxo que ocorre entre as três camadas do Padrão MVC e define seu funcionamento.

Ao se trabalhar com a separação da aplicação nessas três categorias, Model, View e Controller, a pessoa desenvolvedora tem uma série de vantagens, como cita Dall'Oglio (2018), que diz que essa separação permite ao desenvolvedor reutilizar um mesmo objeto de modelo em diversas visualizações diferentes. Imagine uma lista de clientes e uma lista de compras de um cliente ou uma lista de clientes por cidade. São três visualizações diferentes, mas todas tratam de um objeto de modelo de negócios com o mesmo domínio: o cliente.

Valente (2020) diz que o MVC favorece a especialização do trabalho de desenvolvimento, pois você pode ter desenvolvedores especialistas na implementação de interfaces gráficas, os quais são chamados de desenvolvedores Front-End e, também, desenvolvedores Back-End especialistas em classes de modelo que não precisam conhecer e implementar código de interface de usuários.

A Figura 2 exemplifica, de uma outra maneira, o funcionamento de uma requisição a uma aplicação que utiliza o Padrão MVC:

Assim como visto no item anterior sobre o Modelo Cliente–Servidor, o fato de você trabalhar com aplicações Web e/ou sites faz de você uma pessoa que aplica esse modelo, pois ele é a base da internet que conhecemos hoje, por meio das já citadas requisições (requests) e respostas (responses). Outra forma de aplicar esse conceito está envolvida com a criação de APIs, em que, ao criar uma API, você será o servidor dela, e quem for consumir dos serviços de sua API será categorizado como cliente. 

Já sobre o Padrão MVC, hoje, com o advento dos frameworks — serão abordados em uma lição futura —, que são como bibliotecas que fornecem estruturas que são implementadas em todas as aplicações Web de forma geral, você já usará o MVC, pois a maioria desses frameworks são organizados e estruturados com esse padrão.

Caso você não queira utilizar um framework, ideia que eu desaconselho nos dias de hoje por critérios de mercado e de produtividade, para aplicar o Padrão MVC, basta que você organize seu projeto em pastas, criando três pastas: a pasta Views, a pasta Controllers e a pasta Model. Contudo, não para por aí, para identificar uma classe Model, basta que ela tenha códigos e regras que falam sobre a regra do negócio propriamente dito, e a View para Web ficaria responsável por ter, em seu conteúdo, HTML, CSS e JavaScript, restando, então, para o Controller fazer a intermediação das solicitações da View para a Model e a sua devolução, conforme você pôde ver na Figura 2 desta lição.