Neste material, apresentaremos a você algo como MVC. Vamos falar sobre o que é MVC, abordar a história de sua criação, entender as principais ideias e conceitos inerentes ao MVC, considerar passo a passo como dividir uma aplicação em módulos Model, View, Controller e também escrever uma pequena aplicação web em Spring-Boot e usando Spring-MVC como exemplo, vamos ver como os dados são transferidos do código Java para páginas HTML. Para entender este material, você precisa estar familiarizado com padrões de projeto, especialmente Observer e Facade. Esteja familiarizado com solicitações e respostas HTTP, entenda o básico de html, saiba o que são anotações em Java. Sente-se, faça o chá, prepare a sobremesa, a salada, o prato principal e o primeiro prato. Começamos.
História do MVC
As ideias para o MVC foram formuladas por Trygve Reenskaug enquanto trabalhava na Xerox PARC no final dos anos 70. Naquela época, para trabalhar com computador era impossível prescindir de um diploma acadêmico e do estudo constante de volumosa documentação. O problema que Reenskaug resolveu junto com um grupo de desenvolvedores muito fortes foi simplificar a interação do usuário médio com um computador. Foi necessário criar ferramentas que, por um lado, fossem extremamente simples e compreensíveis e, por outro, permitissem gerir um computador e aplicações complexas. Reenskaug trabalhou na equipe que desenvolveu o computador portátil “para crianças de todas as idades” - Dynabook, bem como a linguagem SmallTalk sob a direção de Alan Kay. Foi então que os conceitos de uma interface amigável foram estabelecidos. O trabalho de Reenskaug com sua equipe influenciou muito o desenvolvimento da área de TI. Vamos apresentar um fato interessante que não está diretamente relacionado ao MVC, mas ilustra a importância desses desenvolvimentos. Em 2007, após a apresentação do iPhone da Apple, Alan Kay disse: “Quando o Macintosh foi lançado, a Newsweek perguntou o que eu achava dele. Eu disse: este é o primeiro computador pessoal digno de crítica. Após a apresentação, Steve Jobs apareceu e perguntou: o iPhone merece críticas? E eu disse, aumente 12 x 20 cm e você conquistará o mundo.” Três anos depois, em 27 de janeiro de 2010, a Apple lançou o iPad de 9,7 polegadas. Ou seja, Steve Jobs seguiu quase literalmente o conselho de Alan Kay. O projeto em que Rennskaug trabalhou durou 10 anos. E a primeira publicação sobre MVC de seus criadores foi publicada 10 anos depois. Martin Fowler, autor de vários livros e artigos sobre arquitetura de software, menciona que aprendeu MVC com uma versão funcional do SmallTalk. Como há muito tempo não havia informações sobre MVC da fonte primária, bem como por uma série de outras razões, surgiu um grande número de interpretações diferentes deste conceito. Como resultado, muitas pessoas consideram o MVC um esquema ou padrão de design. Menos comumente, o MVC é chamado de padrão composto ou uma combinação de vários padrões que funcionam juntos para implementar aplicativos complexos. Mas, na verdade, como dito anteriormente, MVC é principalmente um conjunto de ideias/princípios/abordagens arquiteturais que podem ser implementados de várias maneiras usando vários padrões... A seguir, tentaremos examinar as principais ideias incorporadas no conceito MVC.
O que é MVC: ideias e princípios básicos
VC é um conjunto de ideias e princípios arquitetônicos para a construção de sistemas de informação complexos com uma interface de usuário;
MVC é um acrônimo que significa Model-View-Controller.
Isenção de responsabilidade: MVC não é um padrão de design. MVC é precisamente 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 repetir sempre: “Um conjunto de ideias arquitetônicas...”, chamaremos MVC de padrão. Vamos começar com algo simples. O que está escondido atrás das palavras Model-View-Controller? Ao desenvolver sistemas com interface de usuário, seguindo o padrão MVC, é necessário dividir o sistema em três componentes. Estes, por sua vez, podem ser chamados de módulos ou componentes. Diga o que quiser, mas divida por três. Cada componente terá sua própria finalidade. Modelo. O primeiro componente/módulo é o chamado modelo. Ele contém toda a lógica de negócios do aplicativo. Visualizar. A segunda parte do sistema é a visualização. Este módulo é responsável por exibir os dados ao usuário. Tudo o que o usuário vê é gerado pela visualização. Controlador. O terceiro elo desta cadeia é o controlador. Ele armazena o código responsável pelo processamento das ações do usuário (qualquer ação do usuário no sistema é processada no controlador). O modelo é a parte mais independente do sistema. Tão independente que não deveria 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 Visualização e o Controlador. O principal objetivo da Visualização é fornecer informações do Modelo em um formato amigável. A principal limitação da View é que ela não deve alterar o modelo de forma alguma. O principal objetivo do Controlador é processar as ações do usuário. É através do Controller que o usuário faz alterações no modelo. Mais precisamente, nos dados armazenados no modelo. Deixe-nos dar novamente o diagrama que já foi mostrado a vocês na palestra: De tudo isso podemos tirar uma conclusão completamente lógica. Um sistema complexo precisa ser dividido em módulos. Vamos descrever brevemente as etapas para conseguir tal separação.
Etapa 1: Separe a lógica de negócios do aplicativo da interface do usuário
A ideia chave do MVC é que qualquer aplicação com interface de usuário pode, numa primeira aproximação, ser dividida em 2 módulos: um módulo responsável por implementar a lógica de negócio da aplicação e uma interface de usuário. O primeiro módulo implementará as principais funcionalidades do aplicativo. Este módulo será o núcleo do sistema, no qual o modelo de domínio de aplicação será implementado. No conceito MVC, este módulo será a nossa letra M, ou seja, modelo. O segundo módulo implementará toda a interface do usuário, incluindo a exibição de dados ao usuário e a lógica de interação do usuário com a aplicação. O principal objetivo desta separação é garantir que o núcleo do sistema (Modelo na terminologia MVC) possa ser desenvolvido e testado de forma independente. A arquitetura do aplicativo após tal divisão ficará assim:
Passo 2. Usando o padrão Observer, obtenha ainda maior independência do modelo, bem como sincronização das interfaces do usuário
Aqui perseguimos 2 objetivos:
Obtenha ainda maior independência do modelo.
Sincronize interfaces de usuário.
O exemplo a seguir ajudará você a entender o que significa sincronizar interfaces de usuário. Digamos que compramos um ingresso de cinema online e vemos a quantidade de lugares disponíveis no teatro. Outra pessoa pode comprar um ingresso de cinema ao mesmo tempo que nós. Se este alguém comprar um bilhete antes de nós, gostaríamos de ver que o número de lugares disponíveis para a nossa sessão diminuiu. Agora vamos pensar em como isso pode ser implementado dentro do programa. Vamos supor que temos um núcleo de sistema (nosso modelo) e uma interface (a página web na qual fazemos uma compra). No site, 2 usuários selecionam simultaneamente um assento. O primeiro usuário comprou um ingresso. O segundo usuário precisa exibir essas informações na página. Como isso deveria acontecer? Se atualizarmos a interface do kernel do sistema, nosso kernel, nosso modelo, dependerá da interface. Ao desenvolver e testar o modelo, você deverá ter em mente várias maneiras de atualizar a interface. Para conseguir isso, você precisa implementar o padrão Observer. Com sua ajuda, o modelo envia notificações sobre alterações para todos os assinantes. A interface, sendo tal assinante, receberá uma notificação e atualização. O padrão Observer permite que o modelo, por um lado, informe à interface (visualização e controlador) que ocorreram alterações nela e, por outro lado, realmente “não saiba” nada sobre elas e, assim, permaneça independente. Por outro lado, isso permitirá que as interfaces do usuário sejam sincronizadas.
Passo 3. Dividindo a interface em View e Controller
Continuamos a dividir a aplicação em módulos, mas num nível inferior da hierarquia. Nesta etapa, a interface do usuário (que foi separada em um módulo separado na etapa 1) é dividida em uma visualização e um controlador. É difícil traçar uma linha estrita entre uma visualização e um controlador. Se dissermos que a visão é o que o usuário vê e que o controlador é o mecanismo através do qual o usuário pode interagir com o sistema, há alguma contradição. Os controles, como botões em uma página da web ou um teclado virtual na tela do telefone, são essencialmente parte do controlador. Mas eles são tão visíveis para o usuário quanto qualquer parte da visualização. Aqui estamos falando mais sobre divisão funcional. A principal tarefa da interface do usuário é garantir a interação do usuário com o sistema. Isso significa que a interface possui apenas 2 funções:
exibir e exibir convenientemente informações sobre o sistema para o usuário;
inserir dados e comandos do usuário no sistema (transmiti-los para o sistema);
Estas funções determinam como a interface deve ser dividida em módulos. Como resultado, a arquitetura do sistema fica assim: Portanto, temos uma aplicação de três módulos chamados Model, View e Controller. Para resumir:
Seguindo os princípios do MVC, o sistema precisa ser dividido em módulos.
O módulo mais importante e independente deve ser o modelo.
O modelo é o núcleo do sistema. Você precisa ter a capacidade de desenvolvê-lo e testá-lo independentemente da interface.
Para fazer isso, na primeira etapa da segregação do sistema, é necessário dividi-lo em modelo e interface.
A seguir, utilizando o padrão Observer, fortalecemos o modelo em sua independência e obtemos a sincronização das interfaces de usuário.
A terceira etapa é dividir a interface em um controlador e uma visualização.
Tudo o que é necessário para inserir informações do usuário no sistema está no controlador.
Tudo o que envia informações do sistema para o usuário está à vista.
Ainda há mais uma coisa importante para discutir e você pode beber cacau.
Um pouco sobre a relação entre a View e o Controller e o Model
Quando o usuário insere informações através do controlador, ele faz alterações no modelo. Pelo menos o usuário faz alterações nos dados do modelo. Quando o usuário recebe informações através de elementos de interface (via View), o usuário recebe informações sobre os dados do modelo. Como isso acontece? Como o View e o Controller interagem com o modelo? Afinal, não pode ser que as classes View usem diretamente os métodos das classes Model para ler/escrever dados, caso contrário não pode haver qualquer questão de independência do Modelo. O Modelo representa um conjunto de classes fortemente interconectado ao qual, no bom sentido, nem a Visualização nem o Controlador deveriam ter acesso. Para conectar o Modelo com a Visualização e o Controlador, é necessário implementar o padrão de projeto Facade. A fachada do modelo será a própria camada entre o Modelo e a interface, através da qual a Visualização recebe os dados em um formato conveniente, e o Controlador altera os dados chamando os métodos de fachada necessários. Esquematicamente, no final, tudo ficará assim:
MVC: qual é o benefício?
O principal objetivo de seguir os princípios do MVC é separar a implementação da lógica de negócios (modelo) da aplicação de sua visualização (visão). Essa separação aumentará a reutilização de código. Os benefícios de usar MVC são mais óbvios nos casos em que o usuário precisa fornecer os mesmos dados em formas diferentes. Por exemplo, na forma de tabela, gráfico ou gráfico (usando diferentes tipos). Ao mesmo tempo, sem afetar a implementação das visualizações, você pode alterar as reações às ações do usuário (clicar em um botão, inserir dados). Se você seguir os princípios do MVC, poderá simplificar a escrita de programas, aumentar a legibilidade do código e facilitar a expansão e manutenção do sistema no futuro. No material final da série “Introdução ao Desenvolvimento Empresarial”, veremos a implementação do MVC usando Spring-MVC como exemplo. Parte 8. Escrevendo um pequeno aplicativo em spring-boot
De tudo isso podemos tirar uma conclusão completamente lógica. Um sistema complexo precisa ser dividido em módulos. Vamos descrever brevemente as etapas para conseguir tal separação.
Portanto, temos uma aplicação de três módulos chamados Model, View e Controller. Para resumir:
GO TO FULL VERSION