Padrão Arquitetural MVC (Model-View_Controller) - Arquiteturas de Software - Parte IV

Olá sejam bem-vindos ao canal engenharia de software com ênfase uml Eu sou professor gilan gues e eu já atuo na área de modelagem de software há vários anos eu tenho quatro vos publicados sobre o assunto e eu já ministrei diversas palestras de cursos técnicos ou modelagem de software utilizando a linguagem uml na aula de hoje eu vou dar continuidade ao tema sobre arquiteturas de software dessa vez enfocando o padrão arquitetural mvc então vamos iniciar o conteúdo dessa aula Bom primeiramente eu vou falar um pouquinho sobre padrões de arquitetura ou padrões arquiteturais basicamente ah atualmente existem

diversos padrões de arquitetura um padrão de arquitetura ele descreve uma arquitetura de software que foi comprovadamente bem sucedida em uma determinada situação Então os padrões de arquitetura eles são descrições abstratas estilizadas de boas práticas que foram experimentadas testadas em diferentes sistemas e ambientes e que foram e que se demonstraram ser bem-sucedidas então o padrão eh de arquitetura é uma descrição dessa dessa solução que pode ser reaproveitada em situações semelhantes então no momento que eu consigo aplicar um padrão já existente para o desenvolvimento do meu software isso diminui a complexidade do desenvolvimento diminui o tempo de

desenvolvimento e o custo de desenvolvimento existem situações em que nenhum padrão pode se adequar Então eu tenho que criar uma arquitetura nova isso é muito mais caro muito mais demorado e tem um custo muito maior então se for possível aplicar um padrão de arquitetura é melhor então a função do engenheiro de software ter conhecimento sobre quais os padrões de arquitetura que existem atualmente quais são seus pontos fortes quais são seus pontos fracos Em que em que situações eles são mais adequados eh a decisão sobre o padrão de arquitetura mais adequado é fortemente influenciada pelos pelos

requisitos não funcionais os requisitos não funcionais identificam características gerais que devem ser obedecidas por um software como um todo ou pelo menos por grande parte dele então alguns exemplos de eh requisitos não funcionais também conhecidos como atributos de qualidade são desempenho escalab idade confiabilidade portabilidade segurança proteção usabilidade manutenibilidade entre outros bom então um padrão de arquitetura ele deve descrever uma organização de sistema bem sucedida em Sistemas anteriores e ele deve incluir informações de quando o uso desse padrão É adequado seus pontos fortes e os seus pontos fracos a Ah então vamos começar a falar sobre

padrão de arquitetura mvc ou Model View Controller ou modelo visão controlador ele se baseia na filosofia ou na conclusão de que as interfaces com usuários em geral São a parte mais modificada de uma aplicação interativa então eles consideram que é importante manter as modificações da interface separadas do resto do software ah acontece frequentemente de que usuários desejarem ver um determinado dado uma determinada informação sob diferentes perspectivas ou ainda eles podem acessar essas informações por dispositivos diferentes pode ser um momento por laptop e um outro momento pode ser por eh um celular por exemplo então eles

podem querer ver uma tabela ou um gráfico de barras em situações diferentes ambas as represent ações irão refletir o estado corrente de um determinado objeto então eh essas seriam duas visões diferentes duas perspectivas diferentes da mesma informação Ah então nós temos um problema que o esse padrão arquitetural Tenta resolver como a interface com o usuário pode ser mantida separada da funcionalidade da aplicação e ainda assim ser responsiva para as entradas do usuário e para as as alterações nos dados da aplicação ainda como múltiplas visões de interface com usuário podem ser criadas mantidas e coordenadas quando

os dados da aplicação mudam bom Ah então na arquitetura mvc a as noções de separação e Independência elas são fundamentais para o projeto da arquitetura porque elas permitem que as alterações sejam localizadas e Independentes então o padrão mvc ele separa os elementos de um sistema basicamente em três grupos três módulos e permite fazer alterações nesses módulos de maneira independente sem que afetem os outros então como eu falei o padrão o padrão mvc ele é estruturado em três módulos lógicos que interagem entre si os módulos são controle e modelo a visão ela define e gerencia como

os dados serão apresentados ao usuário o controle ele gerencia a interação do usuário e Repassa instruções para a visão e o modelo quando achar necessário essencialmente a visão Avisa ao controle de que um evento ocorreu o controle interpreta se esse evento ele é relevante E caso positivo ele pode solicitar ao modelo para para executar algo ou que a visão apresente algo para o usuário e nós temos o módulo de modelo que ele gerencia o sistema de dados e as operações associadas a esses dados e também contém toda a lógica do negócio Ah existe muita gente

que implementa o padrão mvc concentrando a lógica de negócio no controle isso não está correto de acordo com esse padrão a lógica de negócios tem que estar no modelo não é correto criar classes que só possuam Gets e sets Ahã então o padrão de arquitetura mvc ele é utilizado quando Existem várias maneiras de se visualizar e interagir com os dados e também quando não se tem conhecimento sobre os futuros requisitos de interação e de como os dados deverão ser apresentados Então esse padrão ele permite que os dados sejam alterados de maneira Independente da sua representação

e permite que a representação seja alterada e independente da forma como os dados são geridos então ele permite que os mesmos dados sejam apresentados de diversas maneiras ele possui diversas visões desses dados e então no momento que e permitindo aí da que as alterações feitas em uma representação também apareçam em todas as outras Aqui nós temos a exemplo de padrão de arquitetura mvc baseado no summerville onde nós temos os modelos visão controlador e modelo eh isso eh esse padrão essa esse padrão de arquitetura eh ainda sem utilizar navegadores internet então no na visão nós temos

o a renderização de modelos a solicitação de atualização de modelos e o envio de evento de usuário para o controlador Ah no controlador ele mapeia as ações do usuário para atualizar o modelo e seleciona as visões então ele determina que visões devem ser apresentadas que informações devem ser apresentadas e a visão Avisa o controlador dos eventos do usuário que ocorrem sobre ela o controlador eh quando ocorre mudanças de estado ele solicita que o modelo eh Execute determinadas métodos determinadas funcionalidades e o modelo ele também ele notifica a visão de mudanças de estado H toda a

todo o estado da aplicação é encapsulado pelo modelo então de novo a lógica do negócio fica aqui eh a visão ela faz consultas do do Estado determinadas eh determinados dados determinadas informações determinados objetos e o modelo ele notifica a visão eventualmente Sobre a alteração nesses dados Este é o padrão de arquitetura mvc de acordo com o summerville existem alguns autores que representam esse padrão de uma forma um pouco diferente alguns autores dizem que ah a visão não deve interagir com o modelo a visão só deve interagir com o controlador mas outros dizem que se for

uma interação pequena pode haver uma interação entre o modelo e a visão Ah aqui nós temos basicamente o mesmo padrão de arquitetura mas dessa vez utilizando o navegador internet então há uma interação da Visão com esse navegador então a visão ela apresenta págin dinâmicas e também eh geração e gerenciamento de formulários ela segue repassando os eventos para o usuário em geral através do navegador Ah o controlador ele faz o processamento de soluções solicitações http ã ele valida dados aqui segundo o sum ele contém a lógica da aplicação mas não a lógica de negócios ã ele

então ele interpreta eventos eh do que ocorre sobre a visão se achar necessário ele manda a visão apresentar determinados formulários determinadas informações ele faz solicitações de atualização e de execuções de de métodos contidos na lógica de negócio do modelo e o modelo ele encapsula a lógica de negócios e o banco de dados eh o banco de dados pode ser um pouco de exagero muitas vezes pode ter um módulo independente só para trabalhar com a persistência dos dados e o modelo ele notifica a visão de atualização de dados e a visão ela pode fazer solicitação de

atualizações diretamente ao modelo de novo esta é a visão do summerville existe alguns autores que fazem outras representações dizendo que a visão na verdade não deve se comunicar diretamente com modelo mas somente com o controlador Tá mas de acordo com summerville este é o padrão de arquitetura mvc bom ã então no padrão de arquitetura mvc eu posso ter muitas classes de visão muitas classe controladora e muitas classes eh de entidade contidas no módulo de modelo eh na verdade eh eu posso ter uma visão para cada forma como as informações vão ser apresentados uma classe de

visão para isso ah eu posso eh conter num classe Deão só várias formas de apresentação Mas isso pode sobrecarregar essas classes e eu posso ter um controlador para interpretar cada uma das visões possíveis ou eu posso ter um controlador geral que se responsabilize por interpretar todos os eventos nas visões e as atualizações nas nas classes de visão só que isso pode deixar o controlador sobrecarregado bom ã aqui eu tenho um módulo de visão referente ao sistema de controle bancário que eu tenho utilizado como exemplo eh nas minhas aulas sobre o a linguagem uml então aqui

eu tenho uma visão para abertura de conta uma visão para manutenção do uma visão pro processo de abertura de conta uma visão para processo de manutenção do cadastro cliente uma visão para o processo de realizar depósito uma visão para o processo de realizar saque uma visão para o processo de emitir saldo uma visão para processo de emitir extrato e uma visão para o processo de encerramento de conta Claro eu poderia ter múltiplas visões para cada um desses processos aqui nós estamos representando uma simplificação do módulo de visão e claro cada uma dessas visões poderia ter

métodos para a apresentação eh de informações em formatos diferentes e aqui eu tenho um controlador para cada um daqueles processos para cada um daquela para cada uma daquelas visões Eu tenho um controle um controlador para abertura de conta um controlador para manutenção do cliente um controlador pro processo de realizar depósito e assim vai e Aqui nós temos deu um pequeno probleminha e Aqui nós temos o o módulo de modelo que contém as classes de Entidade do meu software classes de entidades são classes relacionadas diretamente ao domínio do problema e que normalmente serão persistentes e normalmente

terão muitos objetos classes persistentes são classes cujos objetos precisam ser gravados em disco então Aqui nós temos as classes de entidade do do meu sistema e elas contém a lógica do negócio elas não devem conter somente Gets e sets Aliás na umr nós não representamos Gets e sets porque são métodos bastante inúteis que não acrescentam muita informação nós normalmente nos concentramos na lógica do negócio certo então a lógica do negócio deve estar no módulo de modelo não nas controladoras as controladoras têm os seus próprios métodos e suas próprias funções mas a lógica do negócio deve

estar na no módulo de modelo Aqui nós temos o mesmo padrão mvc dessa vez representado por meio de pacotes H do diagrama de pacotes da uml pacotes e dependências que são o tipo de associação entre os pacotes eh então nós temos um pacote representando modulo de divisão que contém as classes divisão como eu falei pode haver mais classes de divisão se for considerado necessário aqui eu crii uma classe visão para cada processo do sistema Aqui nós temos o pacote representando módulo de Model modelo que contém as controladoras e Aqui nós temos um pacote que contêm

a que representa o módulo de modelo com as classes de entidade aqui tem um pacote extra para representar o o as classes de repositório que são padrão de eh pseudo persistência que gerenciam coleções de objetos de uma determinada classe então aqui a visão ela Repassa os eventos para paraas classes de controle para as instâncias das classes de controle obviamente e as controladoras elas solicitam a que a visão apresente formulários e informações para os usuários e quando ela acha necessário ela solicita que o modelo as as instâncias das classes de modelo executem determinadas operações eh relativas

à lógica do negócio Ah eventualmente a visão ela pode solicitar atualizações de dados diretamente ao modelo quando não há um evento diferente é só para atualizar os dados e o modelo ele envia notificações de mudanças de dados quando simplesmente os dados foram atualizados para que a visão não precise fazer uma solicitação para o controlador e a controladora passar essa solicitação para o modelo então h para tornar o processo mais ágil quando não é um evento diferente é somente uma atualização de dados a visão pode eh trabalhar direta amente com o módulo de modelo de novo

esta é uma forma de representar o padrão IVC alguns autores defendem que não que a visão não deve trabalhar com modelo deve trabalhar somente com a controladora Mas eu prefiro adotar esse modelo por ser um pouco mais eh ágil mais dinâmico em termos de eh não ter que sobrecarregar a controladora para mesmo quando é simplesmente uma atualização de dados ã a Aqui nós temos um pequeno diagrama de sequência que ilustra um pouco ã o padrão mvc Como funciona o processo do padrão mvc então o usuário ele faz uma situação uma solicitação de visualização de dados

para um objeto de uma classe de visão esse objeto de uma classe visão como é simplesmente uma visualização de dados ele pode obter os dados direto de um objeto de uma classe de entidade ele Repassa os dados diretamente paraa visão agora quando ocorre um evento eh a visão ela Repassa essa requisição para a controladora e a e ela se achar necessário ela faz uma solicitação de atualização de dados no modelo ou de execução de um determinado método relacionado à lógica de negócio de uma de uma Instância de uma classe entidade do modelo e depois ele

notifica o resultado da Visão ou manda que o uma classe uma Instância de uma classe visão atualize seus dados apresente atualize os dados apresentados ao usuário eh pontos fortes da arquitetura mvc permite que os dados sejam alterados de maneira Independente da sua representação e vice--versa apoia a apresentação dos mesmos dados de diversas maneiras pontos fracos ã quando o modelo de dados e as interações é elação relativamente Simples então adotar arquitetura mvc pode exigir que seja criado código adicional desnecessário e tornar o código mais complexo do que precisaria ser quando usar se usa arquitetura mvc quando

Existem várias maneiras de visualizar os dados quando Existem várias maneiras de interagir com esses dados quando existe a necessidade de mudar as interfaces com bastante frequência sem que as regras de negócio sejam alteradas e é isso nós concluímos mais essa aula sobre arquitetura de software eu espero que essa aula tenha sido útil se vocês gostaram dessa aula então eu peço que vocês curtam o vídeo compartilhem com quem possa ter interesse e se ainda não estão inscritos eu peço que se inscrevam no canal obrigado pela atenção nós nos vemos nas próximas aulas