25/09/2017 Model-View-Controller

Model-View-Controller
Conteúdo aposentado

Esse conteúdo está desatualizado e já não é mantido. É fornecido como uma cortesia para
pessoas que ainda estão usando essas tecnologias. Esta página pode conter URLs válidos
quando publicados originalmente, mas agora, links para sites ou páginas que não existem
mais. Consulte a orientação de padrões e práticas para as informações mais atualizadas.

Versão 1.0.1

Comunidade GotDotNet para colaboração nesse padrão

Lista completa de padrões e práticas

Contexto
O objetivo de muitos sistemas de computador é recuperar dados de um armazenamento de dados e exibi-lo para o
usuário. Depois que o usuário alterar os dados, o sistema armazena as atualizações no armazenamento de dados. Como o
fluxo de informações é entre o armazenamento de dados e a interface do usuário, você pode estar inclinado a amarrar
essas duas peças juntas para reduzir a quantidade de codificação e melhorar o desempenho da aplicação. No entanto,
essa abordagem aparentemente natural tem alguns problemas importantes. Um problema é que a interface do usuário
tende a mudar muito mais freqüentemente do que o sistema de armazenamento de dados. Outro problema com o
acoplamento dos dados e das partes da interface do usuário é que os aplicativos de negócios tendem a incorporar lógica
de negócios que vai muito além da transmissão de dados.

Problema
Como modularizar a funcionalidade da interface do usuário de um aplicativo da Web para que você possa facilmente
modificar as partes individuais?

Forças
As seguintes forças atuam em um sistema neste contexto e devem ser reconciliadas à medida que você considera uma
solução para o problema:

A lógica da interface do usuário tende a mudar com mais freqüência do que a lógica do negócio, especialmente em
aplicativos baseados na Web. Por exemplo, novas páginas de interface do usuário podem ser adicionadas, ou layouts de
páginas existentes podem ser arrastados. Afinal, uma das vantagens de uma aplicação thin client baseada na Web é o fato
de que você pode alterar a interface do usuário a qualquer momento sem ter que redistribuir o aplicativo. Se o código de
apresentação e a lógica de negócios forem combinados em um único objeto, você deve modificar um objeto que

https://msdn.microsoft.com/en-us/library/ff649643.aspx 1/6
25/09/2017 Model-View-Controller

contenha lógica comercial sempre que você alterar a interface do usuário. Isto é susceptível de introduzir erros e exigir o
reexame de toda a lógica comercial após cada alteração mínima da interface do usuário.

Em alguns casos, o aplicativo exibe os mesmos dados de maneiras diferentes. Por exemplo, quando um analista prefere
uma vista de folha de cálculo de dados, enquanto a gerência prefere um gráfico de torta dos mesmos dados. Em algumas
interfaces de usuário de rich-client, várias visualizações dos mesmos dados são exibidas ao mesmo tempo. Se o usuário
alterar os dados em uma única visão, o sistema deve atualizar todas as outras visualizações dos dados automaticamente.

O design de páginas HTML visualmente atraentes e eficientes geralmente requer um conjunto de habilidades diferente do
que o desenvolvimento de lógica comercial complexa. Raramente uma pessoa tem ambos os conjuntos de
habilidades. Portanto, é desejável separar o esforço de desenvolvimento dessas duas partes.

A atividade da interface de usuário geralmente consiste em duas partes: apresentação e atualização. A parte de
apresentação recupera dados de uma fonte de dados e formata os dados para exibição. Quando o usuário executa uma
ação com base nos dados, a parte de atualização passa o controle de volta para a lógica de negócios para atualizar os
dados.

Em aplicativos da Web, uma solicitação de página única combina o processamento da ação associada ao link que o
usuário selecionou com a renderização da página de destino. Em muitos casos, a página alvo pode não estar diretamente
relacionada à ação. Por exemplo, imagine um aplicativo Web simples que mostre uma lista de itens. O usuário retorna à
página da lista principal depois de adicionar um item à lista ou excluir um item da lista. Portanto, o aplicativo deve
renderizar a mesma página (a lista) depois de executar dois comandos bastante diferentes (adicionar ou excluir) - tudo
dentro da mesma solicitação HTTP.

O código da interface do usuário tende a ser mais dependente do dispositivo do que a lógica de negócios. Se você quiser
migrar o aplicativo de um aplicativo baseado em navegador para suportar assistentes digitais pessoais (PDAs) ou celulares
habilitados para Web, você deve substituir grande parte do código da interface do usuário, enquanto que a lógica do
negócio pode não ser afetada. Uma separação limpa dessas duas partes acelera a migração e minimiza o risco de
introduzir erros na lógica do negócio.

Criar testes automatizados para interfaces de usuário geralmente é mais difícil e demorado do que para lógica de
negócios. Portanto, reduzir a quantidade de código diretamente vinculada à interface do usuário aumenta a capacidade
de aplicação.

Solução
O padrão Model-View-Controller (MVC) separa a modelagem do domínio, a apresentação e as ações com base na entrada
do usuário em três classes distintas [Burbeck92]:

Modelo . O modelo gerencia o comportamento e os dados do domínio do aplicativo, responde aos pedidos de
informações sobre seu estado (geralmente da visualização) e responde às instruções para mudar o estado (geralmente do
controlador).

Veja . A vista gerencia a exibição de informações.

Controlador . O controlador interpreta as entradas de mouse e teclado do usuário, informando o modelo e / ou a

exibição para mudar, conforme apropriado.

A Figura 1 mostra a relação estrutural entre os três objetos.

https://msdn.microsoft.com/en-us/library/ff649643.aspx 2/6
25/09/2017 Model-View-Controller

Figura 1: estrutura de classe MVC

É importante notar que tanto a vista quanto o controlador dependem do modelo. No entanto, o modelo não depende
nem da vista nem do controlador. Este é um dos principais benefícios da separação. Esta separação permite que o modelo
seja construído e testado independentemente da apresentação visual. A separação entre exibição e controlador é
secundária em muitas aplicações rich-client e, de fato, muitas estruturas de interface de usuário implementam as funções
como um objeto. Em aplicações Web, por outro lado, a separação entre a visualização (o navegador) eo controlador (os
componentes do lado do servidor que lidam com a solicitação HTTP) está bem definida.

Model-View-Controller é um padrão de design fundamental para a separação da lógica da interface do usuário da lógica
de negócios. Infelizmente, a popularidade do padrão resultou em uma série de descrições defeituosas. Em particular, o
termo "controlador" foi usado para significar coisas diferentes em diferentes contextos. Felizmente, o advento dos
aplicativos da Web ajudou a resolver alguma ambiguidade porque a separação entre a visão e o controlador é tão
aparente.

Variações

Na programação de aplicativos no Smalltalk-80: Como usar Model-View-Controller (MVC) [Burbeck92], Steve Burbeck

descreve duas variações de MVC : um modelo passivo e um modelo ativo.

O modelo passivo é empregado quando um controlador manipula o modelo exclusivamente. O controlador modifica o
modelo e, em seguida, informa a visão de que o modelo mudou e deve ser atualizado (consulte a Figura 2). O modelo
neste cenário é completamente independente da visão e do controlador, o que significa que não há nenhum meio para
que o modelo relate mudanças em seu estado. O protocolo HTTP é um exemplo disso. Não existe uma maneira simples
no navegador de obter atualizações assíncronas do servidor. O navegador exibe a exibição e responde à entrada do
usuário, mas não detecta mudanças nos dados no servidor. Somente quando o usuário solicita explicitamente uma
atualização, o servidor é interrogado para as mudanças.

https://msdn.microsoft.com/en-us/library/ff649643.aspx 3/6
25/09/2017 Model-View-Controller

Figura 2: Comportamento do modelo passivo

O modelo ativo é usado quando o modelo muda de estado sem o envolvimento do controlador. Isso pode acontecer
quando outras fontes estão alterando os dados e as alterações devem ser refletidas nas visualizações. Considere uma
exibição de ticker. Você recebe dados de estoque de uma fonte externa e deseja atualizar as visualizações (por exemplo,
uma faixa de ticker e uma janela de alerta) quando os dados do estoque mudam. Como somente o modelo detecta
mudanças em seu estado interno quando ocorrem, o modelo deve notificar as visualizações para atualizar a exibição.

No entanto, uma das motivações do uso do padrão MVC é tornar o modelo independente das visualizações. Se o modelo
tivesse que notificar as visualizações das mudanças, você reintroduziria a dependência que estava procurando
evitar. Felizmente, o padrão Observer [Gamma95] fornece um mecanismo para alertar outros objetos de mudanças de
estado sem apresentar dependências sobre eles. As visualizações individuais implementam o Observadorinterface e
registre-se com o modelo. O modelo rastreia a lista de todos os observadores que se inscrevem nas mudanças. Quando
um modelo muda, o modelo itera através de todos os observadores registrados e notifica-os sobre a mudança. Essa
abordagem geralmente é chamada de "publicar-assinar". O modelo nunca requer informações específicas sobre
quaisquer visualizações. Na verdade, em cenários em que o controlador precisa ser informado das mudanças do modelo
(por exemplo, para ativar ou desativar as opções do menu), todo o controlador tem que fazer é implementar
a interface Observer e se inscrever nas mudanças do modelo. Em situações em que há muitas visualizações, faz sentido
definir múltiplos assuntos, cada um dos quais descreve um tipo específico de mudança de modelo. Cada visualização
pode então se inscrever apenas em tipos de mudanças relevantes para a visualização.

A Figura 3 mostra a estrutura do MVC ativo usando Observer e como o observador isola o modelo de referenciar
visualizações diretamente.

Figura 3: Usando Observer para desacoplar o modelo da visualização no modelo ativo

A Figura 4 ilustra como o Observer notifica as visualizações quando o modelo muda. Infelizmente, não existe uma boa
maneira de demonstrar a separação do modelo e da visualização em um diagrama de seqüência de linguagem de
modelagem unificada (UML), porque o diagrama representa instâncias de objetos em vez de classes e interfaces.

https://msdn.microsoft.com/en-us/library/ff649643.aspx 4/6
25/09/2017 Model-View-Controller

Figura 4: Comportamento do modelo ativo

Exemplo
Consulte Implementando Model-View-Controller no ASP.NET .

Considerações de teste
A testabilidade é muito melhorada quando você emprega o Model-View-Controller . Testar componentes torna-se difícil
quando eles são altamente interdependentes, especialmente com os componentes da interface do usuário. Esses tipos de
componentes muitas vezes exigem uma configuração complexa apenas para testar uma função simples. Pior ainda,
quando ocorre um erro, é difícil isolar o problema em um componente específico. Esta é a razão pela qual a separação de
preocupações é um driver arquitetônico tão importante. O MVCsepara a preocupação de armazenar, exibir e atualizar
dados em três componentes que podem ser testados individualmente.

Além dos problemas colocados pelas interdependências, as estruturas de interface do usuário são intrinsecamente difíceis
de testar. Testando as interfaces do usuário, é necessário ensaios manuais tediosos (e propensos a erros) ou testes de
testes que simulam ações do usuário. Esses scripts tendem a ser demorados a se desenvolver e quebradiços. O MVC não
elimina a necessidade de teste de interface do usuário, mas a separação do modelo da lógica de apresentação permite
que o modelo seja testado independente da apresentação e reduz o número de casos de teste da interface do usuário.

Contexto resultante
Arquitetar a camada de apresentação em torno do padrão MVC resulta nos seguintes benefícios e responsabilidades:

Benefícios

Suporta várias visualizações . Como a vista está separada do modelo e não há dependência direta do modelo para a
vista, a interface do usuário pode exibir várias visualizações dos mesmos dados ao mesmo tempo. Por exemplo, várias
páginas em um aplicativo da Web podem usar os mesmos objetos do modelo. Outro exemplo é um aplicativo da Web
que permite ao usuário alterar a aparência das páginas. Essas páginas exibem os mesmos dados do modelo
compartilhado, mas mostram de uma maneira diferente.

Acomoda a mudança . Os requisitos da interface de usuário tendem a mudar mais rapidamente do que as regras de
negócios. Os usuários podem preferir cores diferentes, fontes, layouts de tela e níveis de suporte para novos dispositivos,
como telefones celulares ou PDAs. Como o modelo não depende das visualizações, adicionar novos tipos de visualizações
ao sistema geralmente não afeta o modelo. Como resultado, o escopo da mudança é limitado à visão. Este padrão
estabelece as bases para outras especializações deste padrão, como o Controlador de Página e o Controlador Frontal .

Responsabilidades

Complexidade . O padrão MVC introduz novos níveis de indireção e, portanto, aumenta ligeiramente a complexidade da

solução. Também aumenta a natureza do código de interface do usuário, que pode tornar-se mais difícil de depurar.

Custo das atualizações frequentes . Desacoplando o modelo da vista não significa que os desenvolvedores do modelo
podem ignorar a natureza das visualizações. Por exemplo, se o modelo sofrer alterações frequentes, pode inundar as
visualizações com solicitações de atualização. Algumas visualizações, como exibições gráficas, podem levar algum tempo
para renderizar. Como resultado, a exibição pode ficar por trás das solicitações de atualização. Portanto, é importante
manter a visão em mente ao codificar o modelo. Por exemplo, o modelo poderia lote de várias atualizações em uma única
notificação para a exibição.

Variantes
https://msdn.microsoft.com/en-us/library/ff649643.aspx 5/6
25/09/2017 Model-View-Controller

A variante Document-View reconhece as três funções do Model-View-Controller,mas mescla o controlador na vista. O

documento corresponde ao papel do modelo no MVC . Esta variante está presente em muitas plataformas GUI
existentes. Um excelente exemplo de Document-View é o Microsoft Foundation Class Library (MFC) no ambiente Microsoft
Visual C ++. A troca de usar esta variante é que a vista e o controlador estão mais acoplados.

Padrões Relacionados
Para obter mais informações, consulte os seguintes padrões relacionados:

Observador . Esse padrão geralmente é mencionado em conjunto com MVCdevido à necessidade de manter as

visualizações e o modelo associado sincronizados.

O Controlador de Página e o Controlador Frontal descrevem estratégias de implementação para a parte do controlador

dopadrão MVC .

Reconhecimentos
Model-View-Controller começou como uma estrutura desenvolvida por Trygve Reenskaug para a plataforma Smalltalk no
final da década de 1970 [Fowler03]. A versão que acabou de ler faz referência aos seguintes trabalhos:

[Burbeck92] Burbeck, Steve. "Programação de aplicativos no Smalltalk-80: Como usar Model-View-Controller (MVC). "

Universidade de Illinois em Urbana-Champaign (UIUC) Smalltalk Archive. Disponível em: http://st-
www.cs.illinois.edu/users/smarch/st-docs/mvc.html .

[Fowler03] Fowler, Martin. Padrões da arquitetura de aplicativos corporativos . Addison-Wesley, 2003.

[Gamma95] Gamma, Helm, Johnson e Vlissides. Padrões de design: elementos do software reutilizável orientado a
objetos . Addison-Wesley, 1995.

https://msdn.microsoft.com/en-us/library/ff649643.aspx 6/6