Model-view-controller (MVC)

November 8th, 2007 posted by Marcio Rosa

Model-view-controller (MVC) é um padrão de arquitetura de software. Em aplicações complexas, que enviam uma série de dados para o usuário, o desenvolvedor freqüentemente necessita separar os dados (Model) da interface (View). Desta forma, alterações feitas na interface não afetarão a manipulação dos dados, e estes poderão ser reorganizados sem alterar a interface do usuário. O model-view-controller resolve este problema através da separação das tarefas de acesso aos dados e lógica do negócio da apresentação e interação com o usuário, introduzindo um componente entre os dois: o Controller. MVC é usado em padrões de projeto de software, mas MVC abrange mais da arquitetura de uma aplicação do que é típico para um padrão de projeto.

É comum dividir a aplicação em camadas separadas: apresentação (interface), domínio e acesso a dados. Em MVC a camada de apresentação também é separada da view e da controller.

Model

A representação “domínio” específica da informação em que a aplicação opera. Muitas aplicações usam um mecanismo de armazenamento persistente (como banco de dados) para armazenar dados. MVC não cita especificamente a camada para acesso aos dados, porque subentende-se que estes métodos estariam encapsulados pelo Model.

View

“Renderiza” o model em uma forma específica para a interação, geralmente uma interface de usuário.

Controller

Processa e responde a eventos, geralmente ações do usuário, e pode invocar alterações no Model.

MVC é muito visto também em aplicações para Web, onde a View é geralmente a página HTML, e o código que gera os dados dinâmicos para dentro do HTML é o Controller. E, por fim, o Model é representado pelo conteúdo de fato, geralmente armazenado em bancos de dados ou arquivos XML.

Ainda que existam diferentes formas de MVC, o controle de fluxo geralmente funciona como segue:

  1. O usuário interage com a interface de alguma forma (por exemplo, o usuário aperta um botão)
  2. O Controller manipula o evento da interface do usuário através de uma rotina pré-escrita.
  3. O Controller acessa o Model, possivelmente atualizando-o de uma maneira apropriada, baseado na interação do usuário (por exemplo, atualizando os dados de cadastro do usuário).
  4. Algumas implementações de View utilizam o Model para gerar uma interface apropriada (por exemplo, mostrando na tela os dados que foram alterados juntamente com uma confirmação). O View obtém seus próprios dados do Model. O Model não toma conhecimento direto da View.
  5. A interface do usuário espera por próximas interações, que iniciarão o ciclo novamente.