Os princípios do padrão de design MVC

Este código de exemplo não é um código de produção e deve ser usado apenas para fins de treinamento!

Depois de pesquisar vários artigos na internet, cheguei às seguintes descrições dos princípios do padrão de projeto Model-View-Controller:

Input      --> Processing --> Output 
Controller --> Model      --> View

O paradigma MVC é uma maneira de quebrar um aplicativo, ou mesmo apenas uma parte da interface de um aplicativo, em três partes: o modelo, a visualização e o controlador. O MVC foi originalmente desenvolvido para mapear as funções tradicionais de entrada, processamento e saída para o reino da GUI:

<?php
// incorporate our classes.    
include('Framework/Controller.php');
include('Framework/View.php');
include('Controller/Blog.php');
include('Models/Blog.php');

// create controller.
$controller = new Controller_Blog($_GET);

// print out the content of the web-application.
echo $controller->render();

Modelo

Um modelo é um objeto que representa dados ou até mesmo atividades, por exemplo, uma tabela de banco de dados ou mesmo algum processo de máquina de produção no chão de fábrica.
O modelo gerencia o comportamento e os dados do domínio do aplicativo, responde a solicitações de informações sobre seu estado e responde a instruções para alterar o estado.
O modelo representa os dados corporativos e as regras de negócios que controlam o acesso e as atualizações desses dados. Freqüentemente, o modelo serve como uma aproximação de software para um processo do mundo real, portanto, técnicas simples de modelagem do mundo real se aplicam ao definir o modelo.
O modelo é a peça que representa o estado e o comportamento de baixo nível do componente. Ele gerencia o estado e conduz todas as transformações nesse estado. O modelo não tem conhecimento específico de seus controladores ou de suas visualizações. A vista é a peça que gerencia a exibição visual do estado representado pelo modelo. Um modelo pode ter mais de uma visualização.
Observe que o modelo pode não ter necessariamente um armazenamento de dados persistente (banco de dados), mas se tiver, pode acessá-lo por meio de um Data Access Object (DAO) separado.

Visão

Uma visão é uma forma de visualização do estado do modelo.
A visualização gerencia a saída gráfica e / ou textual para a parte da exibição em bitmap que está alocada para seu aplicativo. Em vez de uma exibição em bitmap, a visualização pode gerar saída HTML ou PDF.
A visualização renderiza o conteúdo de um modelo. Ele acessa os dados corporativos por meio do modelo e especifica como esses dados devem ser apresentados.
A visualização é responsável por mapear gráficos em um dispositivo. Uma visualização normalmente tem uma correspondência de um para um com uma superfície de exibição e sabe como renderizar para ela. Uma visualização é anexada a um modelo e renderiza seu conteúdo na superfície de exibição.

Controlador

Um controlador oferece facilidades para alterar o estado do modelo. O controlador interpreta as entradas do mouse e do teclado do usuário, comandando o modelo e / ou a visualização para alterar conforme apropriado.
Um controlador é o meio pelo qual o usuário interage com a aplicação. Um controlador aceita a entrada do usuário e instrui o modelo e a visualização a realizar ações com base nessa entrada. Na verdade, o controlador é responsável por mapear a ação do usuário final para a resposta do aplicativo.
O controlador traduz as interações com a visualização em ações a serem realizadas pelo modelo. Em um cliente GUI independente, as interações do usuário podem ser cliques em botões ou seleções de menu, enquanto em um aplicativo da Web elas aparecem como solicitações HTTP GET e POST. As ações executadas pelo modelo incluem a ativação de processos de negócios ou alteração do estado do modelo. Com base nas interações do usuário e no resultado das ações do modelo, o controlador responde selecionando uma visualização apropriada.
O controlador é a peça que gerencia a interação do usuário com o modelo. Ele fornece o mecanismo pelo qual as alterações são feitas no estado do modelo.

Na linguagem Java, o MVC Design Pattern é descrito como tendo os seguintes componentes:

Um modelo de aplicativo com sua representação de dados e lógica de negócios.
Visualizações que fornecem apresentação de dados e entrada do usuário.
Um controlador para despachar solicitações e controlar o fluxo.
O objetivo do padrão MVC é separar o modelo da vista para que as alterações na vista possam ser implementadas, ou mesmo vistas adicionais criadas, sem ter que refatorar o modelo.

Como eles se encaixam

O modelo, a visão e o controlador estão intimamente relacionados e em contato constante. Portanto, eles devem fazer referência um ao outro. A imagem abaixo ilustra a relação básica modelo-visão-controlador:

The basic MVC relationship = 

User -> uses -> Controller -> manipulates -> Model/Application -> updates -> View -> sees -> User

Mesmo que o diagrama acima seja incrivelmente simples, há algumas pessoas que tentam ler mais sobre ele do que realmente existe, e tentam impor suas interpretações como “regras” que definem o que é o MVC “adequado”. Para colocá-lo da forma mais simples possível, o padrão MVC requer o seguinte:

Deve ter um mínimo de três componentes, cada um dos quais desempenhando as responsabilidades do Modelo, da Visualização ou do Controlador, conforme identificado acima. Você pode incluir quantos componentes adicionais desejar, como um Data Access Object (DAO) para se comunicar com um banco de dados relacional.

Há um fluxo de dados entre cada um desses componentes, de modo que cada um possa cumprir suas responsabilidades designadas nesses dados. O que não é especificado no MVC é como a mecânica desse fluxo deve ser implementada. Os dados podem ser empurrados pelo Modelo para a Visualização, podem ser puxados pela Visualização do Modelo ou puxados para um intermediário (como o Controlador ou um Observador) antes de serem enviados para a Visualização. Não importa como os dados fluem, apenas que fluam. A mecânica real é um detalhe de implementação e, portanto, pode ser deixada para o implementador.
O padrão MVC não identifica de onde cada um desses componentes é instanciado e chamado. Existe um 4º componente místico que supervisiona os outros 3, ou um deles pode supervisionar e dirigir os outros dois? Como isso não é especificado diretamente no MVC, a mecânica real pode ser tratada como um detalhe de implementação separado.

Observe o seguinte:

A saída HTML só pode ser gerada e enviada em um lugar – a Visualização.
As regras de negócios só podem ser aplicadas em um lugar – o modelo.
As instruções SQL só podem ser geradas e executadas em um lugar – o DAO (que pode estar dentro do modelo).

Há quem critique a minha interpretação das “regras” do MVC por ser diferente da deles e, portanto, errada, mas quem pode dizer que a sua interpretação é a única que deveria existir?

Encontre mais aqui https://github.com/gjerokrsteski/easy-php-mvc