O problema MVCé que as pessoas pensam que a visão, o controlador e o modelo devem ser o mais independentes possível um do outro. Eles não pensam nisso como uma visão e um controlador frequentemente interligados M(VC).
O controlador é o mecanismo de entrada da interface do usuário, que geralmente é embaraçado na visualização, principalmente nas GUIs. No entanto, a visualização é emitida e o controlador é inserido. Uma visão geralmente pode funcionar sem um controlador correspondente, mas um controlador geralmente é muito menos útil sem uma visão. Os controladores amigáveis usam a visualização para interpretar as informações do usuário de uma maneira mais significativa e intuitiva. É isso que dificulta a separação do conceito de controlador da visualização.
Pense em um robô controlado por rádio em um campo de detecção em uma caixa selada como o modelo.
O modelo é sobre transições de estado e estado sem conceito de saída (exibição) ou o que está acionando as transições de estado. Posso obter a posição do robô em campo e o robô sabe como mudar de posição (dê um passo à frente / para trás / esquerda / direita. Fácil de visualizar sem uma vista ou um controlador, mas não faz nada útil
Pense em uma visão sem um controlador, por exemplo, alguém em outra sala da rede em outra sala assistindo o robô se posicionar enquanto as coordenadas (x, y) fluem em um console de rolagem. Essa visualização está apenas exibindo o estado do modelo, mas esse cara não tem controlador. Novamente, é fácil visualizar essa visão sem um controlador.
Pense em um controlador sem visão, por exemplo, alguém trancado em um armário com o controlador de rádio sintonizado na frequência do robô. Este controlador está enviando entrada e causando transições de estado sem ter idéia do que está fazendo no modelo (se houver). Fácil de visualizar, mas não é realmente útil sem algum tipo de feedback da visualização.
A maioria das interfaces de usuário amigáveis coordena a visualização com o controlador para fornecer uma interface de usuário mais intuitiva. Por exemplo, imagine uma visualização / controlador com uma tela sensível ao toque mostrando a posição atual do robô em 2-D e permitindo que o usuário toque no ponto na tela que está na frente do robô. O controlador precisa de detalhes sobre a visualização, por exemplo, a posição e a escala da viewport e a posição do pixel tocado em relação à posição do pixel do robô na tela) para interpretar isso corretamente (ao contrário do cara trancado no armário com o controlador de rádio).
Eu já respondi sua pergunta? :-)
O controlador é qualquer coisa que recebe entrada do usuário usada para fazer com que o modelo faça a transição do estado. Tente manter a visão e o controlador separados, mas perceba que eles geralmente são interdependentes entre si, por isso não há problema se o limite entre eles é nebuloso, ou seja, ter a visão e o controlador como pacotes separados pode não ser tão limpo quanto você faria. como, mas tudo bem. Você pode ter que aceitar que o controlador não será separado da visão como é do modelo.
... qualquer validação etc deve ser feita no controlador? Em caso afirmativo, como retorno as mensagens de erro de volta ao View - isso deve passar pelo Modelo novamente ou o Controlador deve enviá-lo diretamente de volta ao View?
Se a validação for feita na View, o que eu coloco no Controller?
Eu digo que uma visão vinculada e um controlador devem interagir livremente sem passar pelo modelo. O controlador recebe a entrada do usuário e deve fazer a validação (talvez usando informações do modelo e / ou da visualização), mas se a validação falhar, o controlador poderá atualizar sua visualização relacionada diretamente (por exemplo, mensagem de erro).
O teste de ácido para isso é perguntar a si mesmo se uma visão independente (ou seja, o cara na outra sala assistindo a posição do robô pela rede) deve ver alguma coisa ou não como resultado do erro de validação de outra pessoa (por exemplo, o cara no armário) tentou dizer ao robô para sair do campo). Geralmente, a resposta é não - o erro de validação impediu a transição de estado. Se não houve transição de estado (o robô não se moveu), não há necessidade de informar os outros pontos de vista. O cara no armário simplesmente não recebeu nenhum feedback de que ele tentou causar uma transição ilegal (sem visão - interface do usuário ruim), e ninguém mais precisa saber disso.
Se o cara com a tela sensível ao toque tentou enviar o robô para fora do campo, ele recebeu uma boa mensagem amigável pedindo que não matasse o robô enviando-o para fora do campo de detecção, mas, novamente, ninguém mais precisa saber disso.
Se outros pontos de vista que precisa de saber sobre esses erros, então você está efetivamente dizendo que as entradas do usuário e quaisquer erros resultantes são parte do modelo e toda a coisa é um pouco mais complicado ...