Introdução à arquitetura MVC
A arquitetura de aplicativo mais popular que todo programador conhece é MVC . MVC significa Model-View-Controller .
Isso não é tanto a arquitetura dos aplicativos quanto a arquitetura dos componentes do aplicativo, mas retornaremos a essa nuance mais tarde. O que é MVC?
MVC é um esquema para separar os dados do aplicativo e a lógica de controle em três componentes separados — modelo, exibição e controlador — para que cada componente possa ser modificado independentemente.
- Model (Modelo) fornece dados e responde aos comandos do controlador alterando seu estado.
- A View é responsável por exibir os dados do modelo para o usuário em resposta às alterações do modelo.
- O Controller (Controller) interpreta as ações do usuário, notificando o modelo da necessidade de mudanças.
Este modelo foi inventado em 1978 (!) Ano. Sim, problemas com arquitetura de software adequada eram relevantes há 50 anos. Aqui está como este modelo é descrito pelo diagrama no original:
O modelo fornece dados e métodos para trabalhar com eles: consultas ao banco de dados, verificando a exatidão. O modelo é independente da visão (não sabe renderizar os dados) e do controlador (não possui pontos de interação com o usuário), fornecendo acesso e gerenciamento dos dados.
O modelo é construído de forma a responder às solicitações alterando seu estado, e a notificação de “observadores” pode ser incorporada. O modelo, devido à independência da representação visual, pode ter várias representações diferentes para um “modelo”.
A visão é responsável por obter os dados necessários do modelo e enviá-los ao usuário. A exibição não processa a entrada do usuário.
O controlador fornece a "comunicação" entre o usuário e o sistema. Controla e direciona os dados do usuário para o sistema e vice-versa. Usa um modelo e uma visão para implementar a ação desejada.
Existe uma certa dificuldade com o fato desse modelo ter evoluído um pouco ao longo das décadas. Ou seja, o nome permaneceu o mesmo, mas a finalidade das peças começou a mudar.
Arquitetura MVC na web
A ideia por trás do padrão de projeto MVC é muito simples: precisamos separar claramente a responsabilidade por diferentes comportamentos em nossas aplicações:
Modelo— processamento de dados e lógica de aplicação.
visualizar— fornecer dados ao usuário em qualquer formato compatível.
controlador- processar as solicitações do usuário e chamar os recursos apropriados.
O aplicativo é dividido em três componentes principais, cada um dos quais é responsável por diferentes tarefas. Vamos examinar mais de perto os componentes de um aplicativo cliente-servidor usando um exemplo.
Controlador
O usuário clica em vários elementos da página no navegador, pelo que o navegador envia várias solicitações HTTP: GET, POST ou outras. O controlador pode incluir o navegador e o código JS que funcionam dentro da página.
A principal função do controlador neste caso é chamar métodos nos objetos necessários, gerenciar o acesso aos recursos para executar tarefas especificadas pelo usuário. Normalmente, o controlador chama o modelo apropriado para a tarefa e seleciona a visualização apropriada.
Modelo
Modelo em um sentido amplo são os dados e regras que são usados para trabalhar com os dados - juntos, eles compõem a lógica de negócios do aplicativo. Projetar um aplicativo sempre começa com a construção de modelos dos objetos nos quais ele opera.
Digamos que temos uma loja online que vende livros, então uma pessoa é apenas um usuário do aplicativo ou também autor de um livro? Essas questões importantes devem ser abordadas durante o projeto do modelo.
Além disso, existem conjuntos de regras: o que pode ser feito, o que não pode ser feito, quais conjuntos de dados são aceitáveis e quais não são. Pode existir um livro sem um autor? E o autor sem livros? A data de nascimento do usuário pode estar no ano 300 e assim por diante.
O modelo dá ao controlador uma visão dos dados que o usuário solicitou (mensagem, página do livro, fotos, etc.). O modelo de dados será o mesmo, não importa como queremos apresentá-lo ao usuário. Portanto, escolhemos qualquer visualização disponível para exibir os dados.
O modelo contém a parte mais importante da nossa lógica de aplicação , a lógica que resolve o problema com o qual estamos lidando (fórum, loja, banco, etc.). O controlador contém principalmente lógica organizacional para o próprio aplicativo (assim como seu gerente de projeto).
Visualizar
View fornece várias maneiras de representar os dados recebidos do modelo. Pode ser um modelo preenchido com dados. Pode haver várias visões diferentes e o controlador escolhe qual é a melhor para a situação atual.
Um aplicativo da Web geralmente consiste em um conjunto de controladores, modelos e visualizações. O controlador pode estar apenas no back-end, mas também pode haver uma variante de vários controladores, quando sua lógica é espalhada também pelo front-end. Um bom exemplo dessa abordagem é qualquer aplicativo móvel.
Exemplo de MVC na web
Digamos que você precise desenvolver uma loja online que venda livros. O usuário pode realizar as seguintes ações: visualizar os livros, cadastrar-se, comprar, adicionar itens ao pedido atual, marcar os livros de que gosta e comprá-los.
Seu aplicativo deve ter um modelo responsável por toda a lógica de negócios. Você também precisa de um controlador que processe todas as ações do usuário e as transforme em chamadas de método da lógica de negócios. No entanto, um método de controlador pode chamar muitos métodos de modelo diferentes.
Você também precisa de conjuntos de visualizações: uma lista de livros, informações sobre um livro, um carrinho de compras, uma lista de pedidos. Cada página de um aplicativo da Web é, na verdade, uma exibição separada que exibe um determinado aspecto do modelo para o usuário.
Vamos ver o que acontece se um usuário abrir uma lista de livros recomendados pela livraria para visualizar os títulos. Toda a sequência de ações pode ser descrita na forma de 6 etapas:
Passos:
- O usuário clica no link "recomendado" e o navegador envia uma solicitação para, digamos, /books/recommendations.
- O controlador verifica a solicitação : o usuário deve estar logado. Ou deveríamos ter coleções de livros para usuários não logados. O controlador então chama o modelo e pede que ele retorne a lista de livros recomendados ao usuário N.
- O modelo acessa o banco de dados, recupera informações sobre livros de lá: livros que são populares no momento, livros comprados pelo usuário, livros comprados por seus amigos, livros de sua lista de desejos. Com base nesses dados, o modelo constrói uma lista de 10 livros recomendados e os devolve ao controlador.
- O controlador recebe uma lista de livros recomendados e a examina. Nesta fase, o controlador toma decisões! Se houver poucos livros ou a lista estiver completamente vazia, ele solicitará uma lista de livros para um usuário não logado. Se houver uma promoção acontecendo agora, o controlador pode adicionar livros promocionais à lista.
- O controlador determina qual página mostrar ao usuário. Pode ser uma página de erro, uma página com uma lista de livros, uma página parabenizando o usuário por se tornar um milionésimo visitante.
- O servidor dá ao cliente a página ( view ) selecionada pelo controlador. É preenchido com os dados necessários (nome de usuário, lista de livros) e vai para o cliente.
- O cliente recebe a página e a exibe para o usuário.
Quais são os benefícios dessa abordagem?
A vantagem mais óbvia que obtemos ao usar o conceito MVC é uma separação clara da lógica de apresentação (interface do usuário) e da lógica do aplicativo (back-end).
A segunda vantagem é a divisão da parte do servidor em duas: um modelo inteligente ( executor ) e um controlador ( centro de decisão ).
No exemplo anterior, houve um momento em que o controller poderia receber uma lista vazia de livros recomendados do modelo e decidir o que fazer com ela. Teoricamente, essa lógica poderia ser colocada diretamente no modelo.
Primeiro, ao solicitar livros recomendados, o modelo decidiria o que fazer se a lista estivesse vazia. Então eu teria que adicionar o código no mesmo lugar, o que fazer se houver uma promoção acontecendo agora, então mais opções diferentes.
Acontece que o administrador da loja queria ver como ficaria a página do usuário sem promoção, ou vice-versa, não há promoção agora, mas ele quer ver como será exibida a promoção futura. E não há métodos para isso. Portanto, optou-se por separar o centro de decisão (controlador) da lógica de negócios (modelo).
Além de isolar as visualizações da lógica do aplicativo, o conceito MVC reduz muito a complexidade de grandes aplicativos. O código está muito mais estruturado, facilitando a manutenção, teste e reutilização de soluções.
Entendendo o conceito de MVC, você, como desenvolvedor, percebe onde precisa adicionar ordenação na lista de livros:
- No nível de consulta do banco de dados.
- Ao nível da lógica de negócio (modelo).
- No nível da lógica de negócios (controlador).
- Na exibição - no lado do cliente.
E esta não é uma pergunta retórica. Agora, pense sobre onde e por que você precisa adicionar o código para classificar a lista de livros.
Modelo Clássico MVC
A interação entre os componentes MVC é implementada de forma diferente em aplicativos da web e aplicativos móveis. Isso ocorre porque o aplicativo da web tem vida curta, processa uma solicitação do usuário e sai, enquanto o aplicativo móvel processa muitas solicitações sem reiniciar.
Os aplicativos da Web geralmente usam o modelo "passivo", enquanto os aplicativos móveis usam o modelo "ativo". O modelo ativo, ao contrário do passivo, permite que você se inscreva e receba notificações de alterações nele. Isso não é necessário para aplicativos da web.
É assim que a interação dos componentes em vários modelos se parece:
Aplicativos móveis (modelo ativo) usam ativamente eventos e o mecanismo de inscrição de eventos. Com essa abordagem, view ( view ) se inscreve nas alterações do modelo. Então, quando algum evento ocorre (por exemplo, o usuário clica em um botão), o controlador é chamado . Ele também fornece ao modelo um comando para alterar os dados.
Se alguns dados foram alterados, o modelo gera um evento sobre a alteração desses dados. Todas as visualizações que se inscreveram neste evento (para as quais é importante alterar esses dados específicos) recebem esse evento e atualizam os dados em sua interface.
Em aplicativos da Web, as coisas são organizadas de maneira um pouco diferente. A principal diferença técnica é que o cliente não pode receber mensagens do lado do servidor por iniciativa do servidor .
Portanto, um controlador em um aplicativo da Web geralmente não envia nenhuma mensagem para a exibição, mas fornece ao cliente uma nova página, que é tecnicamente uma nova exibição ou até mesmo um novo aplicativo cliente (se uma página não souber nada sobre a outra) .
Atualmente, esse problema é parcialmente resolvido usando as seguintes abordagens:
- Consultar regularmente o servidor em busca de alterações em dados importantes (uma vez por minuto ou mais).
- Os WebSockets permitem que um cliente assine as mensagens do servidor.
- Notificações push da Web do lado do servidor.
- O protocolo HTTP/2 permite que o servidor inicie o envio de mensagens para o cliente.