Conceitualmente, estou tentando entender se devo fazer isso:
item = Model()
screen = View()
brain = Controller(item, screen)
ou isto..
brain = Controller()
item = Model(brain)
screen = View(brain)
ou isto..
class Controller():
def __init__(self):
item = Model(self)
screen = View(self)
ou algo completamente diferente?
Respostas:
Para mim, a primeira opção faz sentido. O trabalho do controlador é coordenar entre a vista e o modelo. Desse ponto de vista, faz sentido que o controlador seja aquele que controla as referências à vista e ao modelo.
Você realmente não pode ter um controlador sem um Modelo e uma Visualização, no entanto, faz muito mais sentido apenas ter uma Visualização ou apenas um Modelo (por exemplo, em testes de unidade). É por isso que você deseja passar essas dependências para o Controller, e não as outras duas.
O Modele Viewsão independentes um do outro.
Não pense nissoController como o cérebro da estrutura MVC. Pense nisso como o expedidor que lida com as solicitações do navegador e as envia para o Model. Em seguida, ele pega os dados de Modele os empacota de maneira amigável ao modelo e os envia para a View.
O Modelé o cérebro na estrutura MVC, e este é o lugar onde você deve colocar suas regras de negócios. As regras de negócios são comuns em vários controladores . Portanto, um controlador de documento e um controlador de relatórios podem usar um modelo de usuário para ver quem tem acesso a essas coisas. Você não gostaria de repetir essas regras nos dois controladores.
O Viewdeve usar um modelo HTML para apresentar os dados de uma maneira específica que não seja da fonte de dados. Não deve estar totalmente ligado ao esquema do seu banco de dados. Para mostrar o título de um documento, você teria a visualização gerando o conteúdo de uma variável de modelo chamada document_title, e apenas o Controllersabe como essa variável foi definida e apenas o Modelpor que esse documento tem esse título.
O MVC foi originalmente definido para facilitar a programação de aplicativos de desktop. A visualização inscrita nos eventos do modelo, atualizando a apresentação quando o modelo foi alterado. O controlador apenas traduziu eventos da interface do usuário (por exemplo, pressionar um botão) em chamadas para o modelo. Portanto, o controlador e a visualização dependiam do modelo, mas eram independentes um do outro. O modelo era independente de ambos. Isso permitiu que várias visualizações e controladores funcionassem no mesmo modelo.
A arquitetura "MVC" usada para aplicativos da Web 1.0 (atualização de página inteira, sem AJAX) é um pouco diferente. Uma solicitação da web é despachada para um controlador. O controlador modifica de alguma forma o estado do modelo e envia um ou mais modelos para serem renderizados por uma visualização. O controlador e a visualização dependem do modelo, mas o controlador também depende da visualização.
Com os aplicativos da Web 2.0, estamos retornando à arquitetura clássica do MVC, no lado do cliente . O modelo, a visualização e o controlador residem no lado do cliente como objetos Javascript. O controlador converte eventos do usuário em ações de modelo. As ações do modelo podem ou não resultar em uma solicitação AJAX para o servidor. Novamente, a visualização assina eventos de modelo e atualiza a apresentação de acordo.
A visualização deve assinar alterações no modelo. Há latitude na riqueza de assinaturas, pois elas podem ser detalhadas (mostre-me alterações de inventário para esse item em particular) ou genéricas (o modelo foi alterado); a visualização pode consultar o modelo em resposta à notificação de alteração. A visualização apresenta o conjunto desejado de elementos de modelo na tela, atualizando a tela como ao lidar com notificações de alterações.
O controlador deve enviar alterações ao modelo, como resultado da direção do usuário (por exemplo, comandos de teclado no put, mouse e menu).
O modelo mantém o modelo e uma lista de assinaturas e deve notificar as visualizações das alterações aplicáveis por meio de suas assinaturas.
Também é necessário haver um mecanismo para criar novas visualizações e controladores (já que no MVC você deve ter duas ou mais visualizações do mesmo modelo (elas podem ser a mesma visualização (ponto) ou diferentes vistas (ponto))). Logicamente, podemos considerar que o controlador precisa executar ou ter acesso a uma fábrica de visão e controlador (par), que pode fazer parte do controlador ou de outro componente.
Modelsnão notifica Views. Controllersconsulte as Modelalterações e renderize Viewspara apresentá-las.
MVC é mais como um padrão de modularidade. Seu objetivo é que, sempre que você desejar alterar o layout da interface do usuário (visualização), não seja necessário alterar a lógica da aplicação (controlador) ou o processamento interno de dados (modelo).
Para conseguir isso, o padrão é isolar a lógica de implementação de cada componente do MVC. Ainda assim, é perfeitamente normal que os componentes conheçam as interfaces uns dos outros .
O que eu sempre vi é que o controlador cria ou chama o modelo e a visualização (portanto, conhece sua interface) e o modelo ou a visão pode notificar o controlador em troca (mais como um retorno de chamada ou padrão de observador). A parte importante é que o controlador não está ciente da estrutura do layout.