Parte 7. Apresentando o padrão MVC (Model-View-Controller)

Este material faz parte da série "Introdução ao Desenvolvimento Corporativo". Artigos anteriores:

• sobre networking
• sobre arquitetura de software
• sobre HTTP/HTTPS
• sobre o básico do Maven
• sobre servlets (escrever uma aplicação web simples)
• sobre contêineres de servlet

Neste artigo vamos conhecer algo chamado MVC. Falaremos sobre o que é MVC, abordaremos sua história, exploraremos as ideias e conceitos básicos incorporados no MVC, veremos passo a passo como dividir um aplicativo em módulos Model, View e Controller, escrever um pequeno aplicativo da web usando Spring Boot e, usando Spring MVC como exemplo, veja como os dados são enviados do código Java para as páginas HTML. Para entender este material, você precisa estar familiarizado com os padrões de projeto, especialmente observador e fachada. E esteja familiarizado com as solicitações e respostas HTTP, entenda os fundamentos do HTML e saiba o que são anotações Java. Pegue uma xícara de café e lanche e fique confortável. Vamos começar.

História do MVC

As ideias por trás do MVC foram formuladas por Trygve Reenskaug enquanto trabalhava na Xerox PARC no final dos anos 1970. Naquela época, trabalhar com computadores exigia um diploma e estudo constante de volumosa documentação. A tarefa resolvida por Reenskaug junto com um grupo de desenvolvedores muito fortes foi simplificar a interação de um usuário comum com o computador. Era necessário criar ferramentas que, por um lado, fossem extremamente simples e compreensíveis e, por outro, permitissem o controle de computadores e aplicativos complexos. Reenskaug trabalhou em uma equipe que desenvolveu um laptop "para crianças de todas as idades" - o Dynabook, bem como a linguagem SmallTalk sob a liderança de Alan Kay. Foi quando os conceitos de uma interface amigável foram estabelecidos. Em muitos aspectos, o trabalho realizado por Reenskaug e sua equipe influenciou a evolução da esfera de TI. Aqui está um fato interessante que não se aplica diretamente ao MVC, mas ilustra a importância desses desenvolvimentos. Alan Kaydisse, "Quando cheguei à Apple, em 84, o Mac já havia sido lançado e a Newsweek entrou em contato comigo e perguntou o que eu achava do Mac. Eu disse: 'Bem, o Mac é o primeiro computador pessoal bom o suficiente para ser criticado.' Então, depois de anunciar o iPhone em 2007, ele o trouxe para mim e me entregou. Ele disse: 'Alan, isso é bom o suficiente para ser criticado?' E eu disse: 'Steve, torne-o tão grande quanto um tablet e você dominará o mundo.'" Depois de 3 anos, em 27 de janeiro de 2010, a Apple lançou o iPad com diagonal de 9,7 polegadas. Em outras palavras, Steve Jobs seguiu quase exatamente o conselho de Alan Kay. O projeto de Reenskaug durou 10 anos. Mas a primeira publicação sobre MVC veio à tona depois de mais 10 anos. Martin Fowler, autor de vários livros e artigos sobre arquitetura de software, menciona que estudou MVC usando uma versão funcional do Smalltalk. Como não havia informações sobre o MVC da fonte original por muito tempo e por vários outros motivos, um grande número de interpretações diferentes desse conceito apareceu. Como resultado, muitos consideram o MVC um padrão de design. Menos comumente, o MVC é chamado de padrão composto ou uma combinação de vários padrões que trabalham juntos para criar aplicativos complexos. Mas, como mencionado anteriormente, o MVC é basicamente um conjunto de ideias/princípios/abordagens arquiteturais que podem ser implementadas de várias maneiras usando diferentes padrões... Em seguida, consideraremos as principais ideias incorporadas ao conceito MVC. e por várias outras razões, um grande número de diferentes interpretações desse conceito apareceu. Como resultado, muitos consideram o MVC um padrão de design. Menos comumente, o MVC é chamado de padrão composto ou uma combinação de vários padrões que trabalham juntos para criar aplicativos complexos. Mas, como mencionado anteriormente, o MVC é basicamente um conjunto de ideias/princípios/abordagens arquiteturais que podem ser implementadas de várias maneiras usando diferentes padrões... Em seguida, consideraremos as principais ideias incorporadas ao conceito MVC. e por várias outras razões, um grande número de diferentes interpretações desse conceito apareceu. Como resultado, muitos consideram o MVC um padrão de design. Menos comumente, o MVC é chamado de padrão composto ou uma combinação de vários padrões que trabalham juntos para criar aplicativos complexos. Mas, como mencionado anteriormente, o MVC é basicamente um conjunto de ideias/princípios/abordagens arquiteturais que podem ser implementadas de várias maneiras usando diferentes padrões... Em seguida, consideraremos as principais ideias incorporadas ao conceito MVC.

MVC: Idéias e princípios básicos

• VC é um conjunto de ideias arquitetônicas e princípios para a construção de sistemas de informação complexos com uma interface de usuário
• MVC é uma abreviação que significa: Model-View-Controller

Isenção de responsabilidade: MVC não é um padrão de design. MVC é um conjunto de ideias e princípios arquitetônicos para a construção de sistemas complexos com uma interface de usuário. Mas por conveniência, para não dizer repetidamente "um conjunto de ideias arquitetônicas...", vamos nos referir ao padrão MVC. Vamos começar com o simples. O que está escondido atrás das palavras Model-View-Controller? Ao usar o padrão MVC para desenvolver sistemas com uma interface de usuário, você precisa dividir o sistema em três componentes. Eles também podem ser chamados de módulos ou componentes. Chame-os como quiser, mas divida o sistema em três componentes. Cada componente tem sua própria finalidade. Modelo. O primeiro componente/módulo é chamado de modelo. Ele contém toda a lógica de negócios do aplicativo. Visualizar.A segunda parte do sistema é a visão. Este módulo é responsável por exibir os dados para o usuário. Tudo o que o usuário vê é gerado pela visão. Controlador.O terceiro elo dessa cadeia é o controlador. Ele contém o código responsável por manipular as ações do usuário (todas as ações do usuário são tratadas no controlador). O modelo é a parte mais independente do sistema. Tão independente que não deve saber nada sobre os módulos view e controller. O modelo é tão independente que seus desenvolvedores podem não saber praticamente nada sobre a visão e o controlador. O principal objetivo da visão é fornecer informações do modelo em um formato que o usuário possa consumir. A principal limitação da visão é que ela não deve alterar o modelo de forma alguma. O principal objetivo do controlador é lidar com as ações do usuário. É por meio do controlador que o usuário faz alterações no modelo. Ou mais precisamente, aos dados armazenados no modelo. Aqui está o diagrama que você viu anteriormente na lição: De tudo isso, podemos tirar uma conclusão lógica. Um sistema complexo precisa ser dividido em módulos. Vamos descrever brevemente as etapas para alcançar essa separação.

Etapa 1. Separe a lógica de negócios do aplicativo da interface do usuário

A ideia principal do MVC é que qualquer aplicação com interface de usuário pode ser dividida em 2 módulos: um módulo responsável por implementar a lógica de negócios e a interface de usuário. O primeiro módulo implementará a funcionalidade principal do aplicativo. Este módulo é o núcleo do sistema, onde é implementado o modelo de domínio da aplicação. No paradigma MVC, este módulo é a letra M, ou seja, o modelo. O segundo módulo implementa toda a interface do usuário, incluindo a lógica para exibir dados para o usuário e lidar com a interação do usuário com o aplicativo. O principal objetivo dessa separação é garantir que o núcleo do sistema (o "modelo" na terminologia MVC) possa ser desenvolvido e testado de forma independente. Após fazer essa separação, a arquitetura do aplicativo fica assim:

Etapa 2 Use o padrão observador para tornar o modelo ainda mais independente e sincronizar as interfaces do usuário

Aqui temos 2 objetivos:

1. Obtenha uma independência ainda maior para o modelo
2. Sincronizar interfaces de usuário

O exemplo a seguir ajudará você a entender o que queremos dizer com sincronização de interfaces de usuário. Suponha que estamos comprando um ingresso de cinema on-line e verificamos o número de assentos disponíveis no cinema. Ao mesmo tempo, outra pessoa pode estar comprando um ingresso de cinema. Se essa outra pessoa comprar um ingresso antes de nós, gostaríamos de ver uma diminuição no número de lugares disponíveis para o show que estamos considerando. Agora vamos pensar em como isso pode ser implementado dentro de um programa. Suponha que temos o núcleo do nosso sistema (nosso modelo) e a interface (a página da web para compra de ingressos). Dois usuários estão tentando escolher um assento no teatro simultaneamente. O primeiro usuário compra um ingresso. A página da Web precisa mostrar ao segundo usuário que isso aconteceu. Como isso deveria acontecer? Se atualizarmos a interface do núcleo, então o núcleo (nosso modelo) será dependente da interface. À medida que formos desenvolvendo e testando o modelo, teremos que ter em mente as diversas formas de atualizar a interface. Para conseguir isso, precisamos implementar o padrão observador. Esse padrão permite que o modelo envie notificações de alteração para todos os ouvintes. Como um ouvinte de eventos (ou observador), a interface do usuário recebe notificações e é atualizada. Por um lado, o padrão observador permite que o modelo informe à interface (view e controller) que as mudanças ocorreram sem realmente saber nada sobre isso, permanecendo independente. Por outro lado, permite sincronizar interfaces de usuário. precisamos implementar o padrão observador. Esse padrão permite que o modelo envie notificações de alteração para todos os ouvintes. Como um ouvinte de eventos (ou observador), a interface do usuário recebe notificações e é atualizada. Por um lado, o padrão observador permite que o modelo informe à interface (view e controller) que as mudanças ocorreram sem realmente saber nada sobre isso, permanecendo independente. Por outro lado, permite sincronizar interfaces de usuário. precisamos implementar o padrão observador. Esse padrão permite que o modelo envie notificações de alteração para todos os ouvintes. Como um ouvinte de eventos (ou observador), a interface do usuário recebe notificações e é atualizada. Por um lado, o padrão observador permite que o modelo informe à interface (view e controller) que as mudanças ocorreram sem realmente saber nada sobre isso, permanecendo independente. Por outro lado, permite sincronizar interfaces de usuário.

Passo 3 Separe a interface em view e controller

Continuamos dividindo o aplicativo em módulos, mas agora em um nível inferior na hierarquia. Nesta etapa, a interface do usuário (que separamos em um módulo distinto na etapa 1) é dividida em uma exibição e um controlador. Desenhar uma linha estrita entre a visão e o controlador é difícil. Se dissermos que a visão é o que o usuário vê e o controlador é o mecanismo que permite ao usuário interagir com o sistema, você pode apontar uma contradição. Elementos de controle, como botões em uma página da Web ou um teclado virtual na tela de um telefone, são basicamente parte do controlador. Mas eles são tão visíveis para o usuário quanto qualquer parte da visualização. O que realmente estamos falando aqui é a separação funcional. A principal tarefa da interface do usuário é facilitar a interação do usuário com o sistema.

• saída e exibição conveniente de informações do sistema para o usuário
• inserir dados e comandos do usuário (comunicá-los ao sistema)

Essas funções determinam como a interface do usuário deve ser dividida em módulos. No final, a arquitetura do sistema fica assim: E é assim que chegamos a um aplicativo que consiste em três módulos chamados model, view e controller. Vamos resumir:

1. De acordo com os princípios do paradigma MVC, um sistema deve ser dividido em módulos.
2. O módulo mais importante e independente deve ser o modelo.
3. O modelo é o núcleo do sistema. Deve ser possível desenvolvê-lo e testá-lo independentemente da interface do usuário.
4. Para conseguir isso, na primeira etapa da divisão, precisamos dividir o sistema em um modelo e interface de usuário.
5. Em seguida, usando o padrão observador, reforçamos a independência do modelo e sincronizamos as interfaces do usuário.
6. A terceira etapa é dividir a interface do usuário em um controlador e exibição.
7. Tudo o que é necessário para receber os dados do usuário no sistema está no controlador.
8. Tudo o que é necessário para fornecer informações ao usuário está na exibição.

Só mais uma coisa importante a discutir antes de beber seu chocolate quente.

Um pouco sobre como a view e o controller interagem com o model

Ao inserir informações por meio do controlador, o usuário altera o modelo. Ou, pelo menos, o usuário altera os dados do modelo. Quando o usuário recebe informações por meio de elementos da interface (através da view), o usuário está recebendo informações sobre o modelo. Como isso acontece? Por quais meios a view e o controller interagem com o model? Afinal, as classes da view não podem chamar diretamente os métodos das classes do model para ler/escrever dados. Caso contrário, não poderíamos dizer que o modelo é independente. O modelo é um conjunto de classes intimamente relacionadas às quais nem a visão nem o controlador devem ter acesso. Para conectar o modelo à visão e ao controlador, precisamos implementar o padrão de projeto de fachada. A fachada do modelo é a camada entre o modelo e a interface do usuário, por meio do qual a visualização recebe dados convenientemente formatados e o Controlador altera os dados chamando os métodos necessários na fachada. No final, tudo fica assim:

MVC: O que ganhamos?

O principal objetivo do paradigma MVC é separar a implementação da lógica de negócios (o modelo) de sua visualização (a visão). Essa separação aumenta as possibilidades de reutilização de código. Os benefícios do MVC são mais evidentes quando precisamos apresentar os mesmos dados em diferentes formatos. Por exemplo, como uma tabela, gráfico ou gráfico (usando visualizações diferentes). Ao mesmo tempo, sem afetar a forma como as visualizações são implementadas, podemos alterar a forma como respondemos às ações do usuário (cliques de botão, entrada de dados). Se você seguir os princípios do MVC, poderá simplificar o desenvolvimento de software, aumentar a legibilidade do código e melhorar a extensibilidade e a capacidade de manutenção. No artigo final da série "Introduction to Enterprise Development", veremos uma implementação MVC construída usando Spring MVC. Parte 8. Vamos escrever um pequeno aplicativo usando Spring Boot